How do you determine the right service boundaries when decomposing a monolith into microservices?

Question

Accepted Answer

Determining the right service boundaries is the most critical decision in microservices architecture because poorly drawn boundaries create a distributed monolith that has all the complexity of microservices with none of the benefits. Domain-Driven Design provides the most reliable framework for this decomposition.

The starting point is identifying bounded contexts within the business domain. A bounded context is a logical boundary where a particular domain model applies consistently. In an e-commerce system, the order management context, inventory context, payment context, and shipping context each have their own models and rules. An order in the order context has different attributes and behaviors than an order in the shipping context. These bounded contexts are natural candidates for service boundaries because they represent areas of cohesive business logic with well-defined interfaces between them.

To identify bounded contexts, I work with domain experts and examine the language used by different parts of the business. When the same term means different things to different teams, you are likely looking at a boundary. The word account means something different to the billing team than to the user management team. This linguistic boundary often aligns with a good service boundary.

Several heuristics validate good boundaries. A well-bounded service has high cohesion, meaning the code within it changes together for the same business reasons. It has loose coupling, meaning changes to one service rarely require changes to others. The service can be deployed independently without coordinating with other services. The service owns its data and does not share a database with other services.

Practical decomposition strategies for an existing monolith include the strangler fig pattern, where new functionality is built as services while existing functionality is gradually extracted. Start with the most autonomous components that have clear interfaces and few dependencies. Order processing or notification services often make good candidates for early extraction because they have well-defined inputs and outputs.

Common mistakes include making services too small, sometimes called nanoservices, where each service does so little that the overhead of inter-service communication exceeds the value of separation. Another mistake is splitting services along technical layers rather than business capabilities, creating a UI service, a business logic service, and a data service rather than vertical slices of business functionality. The right service size is one that a small team can own, develop, and deploy independently while containing a complete, cohesive business capability.