Design Method & StylesChapter 14 · Split decisions
Service boundaries
Service boundaries
Where you cut a system decides whether its services can really work on their own. Good cuts follow business areas — each with its own words and data model, like payments or inventory — keep things that change together inside one service, and give each service sole ownership of its data. Bad cuts show up as two services that call each other constantly, changes that need a transaction across services, or services that must be deployed together — a distributed monolith. Team structure pulls the same way — systems end up shaped like the teams that build them.
- Use when
- Deciding how to split a monolith, or where to draw modules inside one · Reviewing a split that keeps needing coordinated releases or cross-service transactions · Reorganizing teams — boundaries and ownership move together
- Avoid when
- Cutting before the domain is understood — early, wrong boundaries are expensive to move once they are network calls · Splitting by technical layer for its own sake
- Trade-offs
- Coarse services are easier to get right and cheaper to run, but couple more work into one release · Fine services isolate change and scaling, but multiply calls, data copies and things that can fail · Private data per service removes schema coupling, but some data is copied and only eventually consistent across services
- Requires
- Modular monolith
3 objectives · 5 misconceptions
- choose Choose service boundaries for Checkout by business capability and bounded context rather than by technical layer, and say which data each service owns.
- predict Predict whether a proposed split will become a distributed monolith from its call pattern, shared data and deploy coupling — chatty calls, cross-service transactions, lockstep releases.
- explain Explain how team structure shapes service boundaries (Conway's law), and why boundaries and team ownership should be set together.
- Not true: The smaller each service, the better the design.
- Not true: A good first split is by technical layer — a UI service, a business-logic service, a data service.
- Not true: Services can share one database schema as long as each has its own code.
- Not true: Each business entity, like a customer, should have one model that every service uses.
- Not true: Two services calling each other many times per request is just normal service traffic.
Practice
No katas practise this yet.