Decompose by Subdomain vs by Business Capability
Both patterns answer the same question: where should the service boundaries go? Business capabilities describe what the business does. Subdomains describe how the problem is modelled and where words change meaning. Neither is better in general: they work at different levels. Capabilities give stable boundaries the whole business understands, and subdomains find the precise model boundaries inside them. Most systems need both, one after the other.
Updated
What is the difference?
| Aspect | By business capability | By subdomain |
|---|---|---|
| The question it asks | What does the business do? | Where does the meaning of the model change? |
| Where boundaries come from | A capability map, built with people who run the business | The domain model: bounded contexts found with domain experts, for example in event storming |
| Main output | A hierarchy of capabilities, each with an owning team | Bounded contexts, each subdomain marked core, supporting or generic, and a context map |
| Shared words such as Order or Customer | Not addressed directly. One capability usually ends up owning the shared model | Handled directly. Each context keeps its own model of the word |
| Where to invest | Capability heat maps rate each capability's strategic value and maturity, to guide investment across the business | Finer-grained: core subdomains get the most effort, generic ones are bought |
| Who can read the result | Anyone in the business, from executives to finance | Mostly engineers and domain experts who know the domain-driven design vocabulary |
| How stable the boundaries are | Very stable. What a business does changes slowly and survives reorganisations | Can shift as the team learns more about the domain and refines its models |
| Effort to apply | Lower. A first map can come out of one workshop | Higher. Needs domain experts and some practice with domain-driven design |
Where is each approach strongest?
The worked example below shows where subdomain analysis refines a capability map. That does not make it the better method everywhere: each one has situations where it is the stronger choice.
Business capability is the better fit when:
- You need team and ownership boundaries that executives, product and finance can agree on and fund.
- Boundaries have to last through reorganisations, product changes and new leadership.
- The team has little domain-driven design experience or little access to domain experts.
- The domain is fairly simple and data-centred, so words like Customer or Order mean much the same to everyone.
- Much of the landscape is bought software, such as an ERP, CRM or SaaS products, and the question is which system owns what.
- You are planning across a whole portfolio of systems, for example after a merger or when deciding where to invest.
Subdomain is the better fit when:
- The domain is complex, as in logistics, insurance, healthcare or finance.
- The same word means different things to different groups, so one shared model keeps growing.
- You need to decide what to build in-house and what to buy.
- You are drawing precise boundaries for one service or a small group, where an unclear model costs the most.
Step 1: decompose Brindle Eats by business capability
Brindle Eats is a food-delivery platform: consumers order from restaurants, kitchens cook and couriers deliver. Ask the people who run it what the business does, and a first capability map comes out of one workshop.
Restaurant Management
Onboard restaurants, manage menus and opening hours
Consumer Management
Sign-up, profiles, saved addresses
Order Management
Take orders and track them to completion
Delivery Management
Assign couriers and track deliveries
Accounting
Charge consumers, pay restaurants and couriers
Result: five services, one per capability, each with an owning team. Everyone in the company recognises the boxes. So far, so good.
Why does one word cause trouble?
Order Management owns “the order”, but nearly everyone needs it, and each group means something different by it.
| Who | What “Order” means | Fields they care about |
|---|---|---|
| Consumer | What I bought and what it cost | line items, prices, promo code, total ($), payment status |
| Kitchen | What we need to cook, and by when | dishes, modifiers ("no onions"), prep time, ready-by time |
| Courier | What I pick up and where it goes | pickup address, drop-off address, ready time, bag count |
| Finance | Which money moves where | gross amount, fees, tax, restaurant payout, courier payout |
With one Order Service and one Order model:
- The Order model grows to dozens of fields, each added by a different team.
- A kitchen change, such as a new prep station field, means retesting the courier's code.
- Every service calls Order Service for its slice of the data, so it becomes a bottleneck and a single point of failure.
- Nobody can say who approves a change to the Order schema.
Capability decomposition did not cause this, but nothing in it warns you about it either.
How does decomposing by subdomain change the boundaries?
Run an event-storming session with a restaurant manager, a dispatcher and someone from finance, and lay out what happens in order:
- Order placed
- Payment authorized
- Ticket accepted
- Food prepared
- Courier assigned
- Food picked up
- Food delivered
- Restaurant paid
Then listen for where the language changes. Kitchen staff do not say order, they say ticket. Dispatchers talk about deliveries and couriers. Each change of vocabulary marks the edge of a bounded context with its own model. When an order is placed, the kitchen creates a ticket and dispatch creates a delivery, each keeping only the data it needs.
- Restaurant ManagementOne serviceSame
- Restaurant ServiceRestaurant, Menusupporting
Same boundary either way.
- Consumer ManagementOne serviceSame
- Consumer ServiceConsumer, Addresssupporting
Same boundary either way.
- Order ManagementOne serviceSplit
- Order ServiceOrder (the consumer's view)supporting
- Kitchen ServiceTicketsupporting
Kitchen staff talk about tickets, not orders. A ticket has its own lifecycle, so it gets its own context.
- Delivery ManagementOne serviceSplit
- Dispatch ServiceCourier match, ETAcore
- Delivery TrackingDelivery, courier locationsupporting
Matching couriers to orders is what makes Brindle Eats faster than its rivals. That core subdomain gets its own service and the strongest team.
- AccountingOne serviceReshaped
- BillingCharge (via a payment provider)generic
- PayoutsPayout, ledger entrysupporting
Charging cards is generic, so Billing is a thin wrapper around a bought payment provider, not something built in-house.
Which subdomains deserve the most effort?
A capability heat map can show which capabilities matter most. Subdomain classification goes a level finer, inside a capability. That is why Delivery Management split into a core Dispatch Service, and why Billing is bought, not built.
Core
What sets you apart from competitors. Build it in-house, give it your best engineers and change it often.
At Brindle Eats: Courier dispatch and matching, delivery time estimates
Supporting
Needed to run the business but not a differentiator. Build it, and keep it simple.
At Brindle Eats: Restaurant onboarding, menus, kitchen tickets, payouts
Generic
Every business has it. Buy or use an off-the-shelf product unless there is a strong reason not to.
At Brindle Eats: Card payments, sign-in, email and SMS, tax calculation
One “Product” in e-commerce, five models
A capability map often has one Product Management box, which tempts teams to build one Product service with every field. Subdomain analysis finds five small models that share only a product ID.
| Context | What “Product” means | Its fields |
|---|---|---|
| Catalog | Something to show and search | title, description, images, category |
| Pricing | Something with a price that changes | base price ($19.99), discounts, price rules |
| Inventory | A physical item in a warehouse | SKU, warehouse, quantity on hand, reserved |
| Shipping | A parcel to move | weight, dimensions, hazardous goods flag |
| Reviews | Something people rate | rating, review text |
How have real systems drawn these boundaries?
- Grouping services into domains
Uber
In 2020 Uber described Domain-Oriented Microservice Architecture (DOMA). It grouped around 2,200 critical microservices into about 70 domains. Each domain has a gateway as its single entry point, and domains sit in five layers: infrastructure, business, product, presentation and edge. Uber says the approach draws heavily on domain-driven design.
Lesson: Many small services with no domain structure become hard to understand and change. Subdomain thinking can bring that structure back after the fact.
Source: Introducing Domain-Oriented Microservice Architecture (Uber, 2020)
- Business domains inside a monolith
Shopify
In 2019 Shopify described reorganising its Rails monolith around real-world business domains, such as orders, shipping, inventory and billing, instead of models, views and controllers. It enforced the boundaries between these components and chose a modular monolith over microservices.
Lesson: You can find and enforce business boundaries inside one codebase first, and extract services later only where you need them.
Source: Deconstructing the Monolith (Shopify Engineering, 2019)
- Reference application
FTGO
The example application for Chris Richardson's book Microservices Patterns is a food-delivery system much like the one above. Next to its Order Service it has a separate Kitchen Service, along with Consumer, Restaurant, Accounting and Delivery services.
Lesson: A worked codebase you can read to see how a kitchen context sits next to ordering in practice.
Source: ftgo-application (GitHub)
What mistakes do both approaches prevent?
One service per table
CustomerService, ProductService and OrderService as thin wrappers over tables. Every business operation becomes a chain of calls, and the logic has no home.
One service per technical layer
A UI service, a business logic service and a data service. Every feature has to change all three.
Copying the org chart
Boundaries that follow today's departments break at the next reorganisation. Capabilities change more slowly than departments.
Too fine-grained too early
One service per entity or use case before you know the domain. Start coarse and split when you see real pressure.
Boundaries without data ownership
A clean service map that still shares one database. The coupling just moves into the schema.
When should you use each?
| Situation | Lean toward |
|---|---|
| A large organisation that needs team boundaries soon | Business capability |
| You already have a capability map or an enterprise architecture function | Business capability |
| Much of the landscape is bought software, such as an ERP, CRM or SaaS | Business capability |
| Little access to domain experts or experience with domain-driven design | Business capability |
| A complex domain, such as logistics, insurance, healthcare or finance | Subdomain |
| The same word means different things to different teams | Subdomain |
| You need to decide what to build and what to buy | Subdomain |
| A small team and a simple domain | Either, or a modular monolith first |
A practical recipe that uses both:
- Sketch the capability map. Get rough boxes that make sense to the business, and match them to teams.
- Event-storm across the boxes. Find where the language changes, and move boundaries to follow it.
- Classify each subdomain. Core, supporting or generic. Put effort where it differentiates, and buy the rest.
- Draw the context map. Decide how contexts talk: events, APIs and translation at the edges.
- Extract only where it pays. Start as a modular monolith if unsure, and split out services where scaling, release speed or team autonomy need it.
Read the full pattern pages for Decompose by Business Capability and Decompose by Subdomain, or see how teams line up with these boundaries in teams and ownership.
What next?
- Test yourself
Decomposition questions
Scenario questions on where to draw service boundaries, with an explanation for every answer.
- Try it hands-on
Conway's Law lab
Organise the same product by layer, by capability or into tiny teams, and watch handovers and lead time change.
Found it useful? Share it with your team: