Hacker News Reader

Comment by zeroc8 | Hacker News Reader

I'm in the midst of an event driven microservice project. On our first try, we've created a distributed monolith. That's why we decided to rewrite it in a more DDD driven way. I've started reading the blue book, the red book and Scott Millett's "Patterns and Principles of DDD". But the most helpful book I've found so far was "Domain-Driven Design in PHP", which I find a lot easier to grasp thanks to its hands on approach.

That said, as a Go/Javascript person I really appreciate another book on the topic. I appreciate the effort and I am going to buy it.

View on HN

This is really the big problem with DDD microservices. Whilst I'm a huge fan of the two, my go to is to always start out with a monolith and enforce boundraries within the application that could potentially become microservices at somepoint in the future. Even go as far as to use an in-memory event-driven system in the monolith. Then and only then when the need arises do we pull it out into it's own microservice.

This has various benefits but the biggest one being you get to play with the design of the 'microservices' before actually committing to making them microservices allowing you to make better informed decisions. The harder part is that it does require stronger discipline and if not done correctly, a harder transition to microservices (e.g. pulling out the components)

This is great approach. Implementing well-designed horizontally-scalable monolith app usually leads to keeping it monolithic for years, saving enormous amount of time, money and effort, keeping devs team compact and agile.

I'm actually doing exactly that, lol.

Do you use c# ? I let only application layers talk to each other for now. Also, i have some issues finding a decent saga to use that stores it's state ( eg. Something like the library Mass transit)

How do you determine when "the need arises?" We've typically used bottlenecks, e.g. one piece of the app could benefit from additional scale while others wouldn't, and gone from there, but I feel like there's a better or more systematic approach that we're missing.

I think this is a great recommendation for any new project that is considering to use Microservices. I like the approach of an in-memory event-driven system. This helps to enforce a message-only relationship between different conceptual parts from the start.

In fact, I did the same in one project. Also, while I am not covering Microservices in my book, the Sample Application uses a similar approach. The different contexts integrate via event communication. At first, this is an in-memory implementation and everything is running in a single process. Later on, it is replaced with a filesystem-based variant and the individual contexts are operated as individual programs.

Why do you need a microservice architecture?

Good question. It's an IOT project with nodes that need to work in an offline situation. The decision was made before I joined the team and there was nothing I could do about it. In the end, it doesn't really matter. Both approaches are legit, if done right. The real problem is that we produced a distributed monolith due to our inexperience. That's what we are trying to fix now.

Fantastic learning experience if nothing else!

Reply on news.ycombinator.com