[harrylucas]

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)

[alex-lawrence]

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.

[pc86]

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.

[NicoJuicy]

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)

[SergeAx]

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.