Great article! In my experience there is a way to start with a modulith that then naturally extends to microservices. I always start with a monolith, but I also always start with domain events as the way state evolves. This is used internally to update databases, but it can also be used to create commands for external services. In my case those were SaaS products we used (Hubspot for marketing, Intercom for customer support, BrightCove for video streaming, etc.). By having event streams from our own system it became somewhat trivial to ensure that those external systems were always in sync with the internal master database of the monolith, by converting internal events to API calls to those external systems. In effect we had a microservices architecture, and in effect all services were independent because all other services were owned by other companies. So if you start with “modulith plus domain events” it can indeed be a way to naturally evolve into microservices, whether internal or external. Some of this is architectural, and some of it comes down to technical decisions around infrastructure (we used EventStore/Kurrent as source of truth for domain events and Neo4j as database projection). FWIW and YMMV.