6.1. Service Decomposition Strategies
Where you draw service boundaries is the single decision that determines whether microservices help or hurt, and it is a modeling problem, not a technical one. Cut along business capabilities and bounded contexts and services stay independent; cut along technical layers and every feature touches every service. This chapter covers Domain-Driven Design as the tool for finding boundaries, Conway’s Law as the force that shapes them anyway, and the distributed-monolith anti-pattern — along with the modular monolith as the honest answer to “should we even split?”
Topics Covered
Section titled “Topics Covered”- 6.1.1. Domain-Driven Design (DDD): Bounded Context and Ubiquitous Language: Introduces DDD’s bounded context and ubiquitous language as the tools for finding natural service boundaries.
- 6.1.2. Drawing Service Boundaries: Conway’s Law: Explains Conway’s Law and the Inverse Conway Maneuver: your architecture will mirror your org chart.
- 6.1.3. The Strangler Fig Pattern: Safe Migration from Monolith: Covers the strangler fig pattern for incrementally replacing a monolith without a risky big-bang rewrite.
- 6.1.4. Decompose by Business Capability vs. Subdomain: Compares decomposing by business capability against decomposing by subdomain for drawing service lines.
- 6.1.5. Anti-Pattern: The Distributed Monolith - How to Avoid It: Names the distributed-monolith anti-pattern and its symptoms: lockstep deploys, shared databases, chatty calls.
- 6.1.6. Service Granularity: How Small Is Too Small?: Reasons about service size in terms of latency and failure budget per network hop, not lines of code.
- 6.1.7. The Modular Monolith: When Not to Distribute: Presents the modular monolith as the honest answer to whether you should distribute at all.