Reusable boundary patterns help teams start from proven structural shapes instead of inventing every service map from scratch. Chapter 11 covers the most useful patterns for service decomposition, from capability-oriented services to workflow-centered coordination and modular-monolith-first extraction.
Read the lessons in order. The first covers the capability-oriented pattern that acts as the baseline for many healthy service designs. The next three explain experience-aligned boundaries, process-centered boundaries, and domain services supported by narrow utility services. The final lesson shows why modular monolith first, extract later is often the safest pattern for growing teams.
If a design discussion is stuck between vague principles and overly specific implementation details, this chapter gives you reusable shapes to compare.
In this section
- Capability-Oriented Service Pattern
A practical lesson on the capability-oriented service pattern, why it is often the default baseline for microservice decomposition, and how to avoid turning capabilities into vague buckets.
- Front-End-Aligned or Experience-Aligned Boundaries
A practical lesson on experience-aligned boundaries, when backends-for-frontends or channel-specific integration layers are useful, and how to avoid turning user-interface structure into weak service decomposition.
- Workflow or Process-Centered Boundaries
A practical lesson on process-centered services, when a workflow coordinator is useful, and how to keep workflow ownership from expanding into orchestration sprawl.
- Domain Service with Supporting Utility Services
A practical lesson on pairing strong domain services with narrow supporting utility services without letting cross-cutting helpers turn into central bottlenecks or domain owners.
- Modular Monolith First, Extract Later
A practical lesson on using a modular monolith as a boundary-first architecture, validating internal seams before extraction, and avoiding the mistake of treating the monolith as temporary chaos.