When breaking a monolithic application into microservices, what does it mean to decompose 'by business capability' (e.g., Order Management, Inventory, Billing) rather than by technical layer (e.g., a separate UI service, a business-logic service, and a database-access service)? Why is the capability-based split generally preferred?

## What a capability boundary is Decomposing **'by business capability'** means drawing service boundaries around a coherent slice of what the business does — Order Management, Inventory, Billing, Customer Identity — rather than around a technical concern that cuts across every business function, such as 'presentation,' 'business rules,' or 'data access.' The mechanism starts before any code is written: teams run a discovery exercise — **event storming**, **capability mapping**, or simply interviewing domain experts — to trace the business's core processes end to end and find the natural seams. A **seam** is a point: - where vocabulary shifts (an 'order' becomes a 'shipment'); - where a different team or department owns the outcome; - or where the sub-process changes at a different rate and for different reasons than its neighbors. Each capability identified this way becomes a candidate service, and it owns: - its own **API**; - its own **business logic**; - and — critically — its own **data**, so that no other service reaches into its database or its internal model to get work done. ## Why the capability axis exists This exists to solve a coupling problem that predates microservices: distributed systems built on technical layering. In a layered split, you might get: | Layered service | What it takes on | |---|---| | `Presentation/API` | all clients call it | | `Business Rules` | all domain logic funnels through it | | `Data Access` | owns the database | On paper this looks like separation of concerns — it is the classic three-tier architecture pattern, just deployed as separate network services instead of in-process layers. In practice, almost every new business feature (adding a discount code, changing how refunds work) has to touch all three layers and be deployed together, because business changes are vertical (cut across a capability) while the split is horizontal (cuts across capabilities). You end up with the operational overhead of microservices — network calls, serialization, separate deploy pipelines — combined with the change coupling of a monolith. **Capability-based decomposition avoids this** because it makes the unit of change (a business feature) match the unit of deployment (a service): a change to how orders are validated lives entirely inside the Order Management service. ## The trade-off The trade-off is real and shows up on both sides. - Capability decomposition demands **upfront domain knowledge** that a technical split doesn't — you need to understand the business well enough to know where the seams actually are, and getting that wrong (drawing a boundary through the middle of a process that should stay together) is expensive to fix later, since it usually means moving data ownership between services. - It also tends to push **cross-cutting concerns** — input validation rules, currency formatting, authentication checks — toward **controlled duplication**: each capability either re-implements a small piece of shared logic or pulls in a shared library, because routing every capability's requests through one central 'Validation Service' would recreate the very technical-layer coupling you were trying to escape. - **A layered split, by contrast,** gives you a single place to put genuinely shared logic and requires less upfront domain modeling — its failure mode just arrives later, as change coupling, rather than upfront as design risk. ## Failure modes The failure mode of getting this wrong is visible in operations long before anyone calls it out in a design review: - deployment calendars where three or four 'independent' services always ship together for a single feature; - pull requests that touch multiple repos for what the business considers one change; - on-call engineers who can't explain what a service does in business terms, only in technical terms ('it's the one that talks to the database'). Another common failure is stopping the capability search too early and naming a service after a system concept rather than a business one — e.g., a 'Cache Service' or a 'Notification Service' that every capability calls for a synchronous business decision, which quietly becomes a new bottleneck layer. ## Where it shows up A well-known real-world illustration is **Amazon's shift** away from a monolithic retail platform toward services owned end-to-end by small ('two-pizza') teams, each responsible for a business capability — Cart, Checkout, Recommendations, Fulfillment — including that capability's data store, with communication only through published APIs, not shared databases. This is frequently cited, including by Amazon's own engineering leadership, as the organizational precondition that made later independent deployability possible. **The counter-example** is common in early 2000s SOA rollouts, where organizations stood up an Enterprise Service Bus and a layer of 'reusable' services (a shared customer-lookup service, a shared pricing-rules service) that every business process had to call through — reintroducing a central coordination point and, functionally, a distributed monolith with extra network hops.