Back to Catalog
Microservices
Service Decomposition
Decompose by Business Capability
Draw service boundaries around what the business does — not how the code is structured.
Intent & Description
Real-world Use Case
E-commerce capabilities: Order Management, Customer Management, Inventory Management, Shipping, Billing. Each becomes a service boundary. Even if the tech stack changes, the capability map stays valid.
Source
📌 TL;DR
Don’t split by tech layers — split by what the business does. Capabilities are stable; code structure isn’t.
Advantages
- Boundaries are stable — business capabilities don’t change as often as tech
- Aligns engineering to business language (ubiquitous language)
- Easy to explain to non-technical stakeholders
- Natural fit for team organization (team per capability)
Disadvantages
- Requires real business analysis — can’t just read the code
- Capabilities can overlap or nest, making boundaries fuzzy
- Doesn’t tell you how big a service should be
- Needs DDD knowledge to apply rigorously