After reading the pros and cons of both camps, the consensus I gather is that, go monolith first then microservice only if you really need to. But then those transitioning from an already big monolith are often struggling.

That said, if you're starting something from scratch, what are ways to design a monolithic app so that it's microservice-ready?

  • 1
    The Twelve-Factor App is a good guideline for both monolithic apps and microservice apps. They aren't really opposites. In many regards, a well-done monolith is kind of like a microservice system with only a single type of service. – amon Apr 26 '19 at 11:13

You could split your application in "bounded contexts" (see Domain Driven Design) and use events to communicate between contexts. The events should only use simple data types that could be easily transferred over the wire later. Direct object references to another bounded countext wouldn't be allowed.

| improve this answer | |

To add to what @deamon said do your vertical slices all the way to the database, don't use referential integrity, use Guids as primary keys, use fields and not entities...

Maybe this can help:



Hope this helps :-)

| improve this answer | |
  • use Guids as primary keys is this a literal primary key? Or just a secondary key to the real auto-incremented primary key of a table? If it's really the primary key, what do you use for sorting? Something like date_created field? – IMB Apr 28 '19 at 10:14
  • 1
    Yes, Guids as literally primary keys, and yes you can sort by date if you need to get the latest but that is a whole separate discussion :-) – Sean Farmar Apr 28 '19 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.