What is the Decompose by Business Capability pattern?
A business capability is something the business does to create value, such as taking payments, managing inventory or shipping orders. You list the capabilities, usually as a hierarchy, and build one service per capability that owns its logic, its data and its API. Capabilities change slowly even when processes and org charts change, so they make stable boundaries.
What problem does the Decompose by Business Capability pattern solve?
Services split along technical lines force almost every feature through several teams. Capabilities are what product work is actually about, so a boundary around one keeps most changes in one place and gives each team a clear thing to own.
How do you implement the Decompose by Business Capability pattern?
- List the capabilities with people who run the business, starting coarse (Order Management, Payments) and refining only where needed.
- Map today's code, data and teams onto those capabilities to see where they overlap.
- Pick one capability with clear inputs and outputs, and give it a service with its own data store.
- Define its public API and the events it publishes. Keep its internal model private.
- Assign one team as the owner of each capability service.
When should you use it?
- You are designing services and want boundaries that make sense to the business, not only to engineers.
- Teams are organised, or could be organised, around products and business areas.
When should you avoid it?
- One small team runs the whole product. Capability modules inside a monolith get you most of the benefit.
- The capability map is a guess. Wrong boundaries are costly once they are network calls.
What do you gain?
- Boundaries that are stable over time
- Clear ownership that the business understands
- Most features stay inside one service
What does it cost?
- Needs input from people outside engineering
- Coarse capabilities can still hide very different subdomains
- Shared concepts such as Customer need care at the edges
What are common mistakes with the Decompose by Business Capability pattern?
- Mistaking a process step or a UI screen for a capability.
- Mapping capabilities but leaving all services on one shared database.
- Splitting every sub-capability into its own service on day one.
Decompose by Business Capability in practice
Tidewell Travel
A booking monolith was organised in technical layers. Adding a cancellation fee touched the UI, pricing logic and data access code owned by three teams, and every release needed a coordination meeting.
The company mapped what the business does (search, pricing, booking, payments, guest messaging) and gave each capability a service and a team. Most features now change one service, and releases stopped needing a meeting.
Example decision record
- Context
- Feature delivery has slowed because every change crosses code owned by several teams in the monolith.
- Decision
- Build new functionality as services aligned with business capabilities, each owned by one team.
- Consequences
- Teams can ship within their capability without coordinating releases.
- Communication between capabilities goes through published APIs or events, not shared code.