Decompose by Business Capability

Business capability is usually the strongest first heuristic for service decomposition because it starts from what the organization must do rather than from how the code or database currently happens to be arranged. Teams often make better boundary decisions when they start with billing, identity, catalog, checkout, or fulfillment than when they start with controllers, schemas, tables, or UI screens. Capability-first thinking creates better questions about responsibility, outcomes, and ownership.

This matters because service boundaries are expensive. They affect runtime behavior, team coordination, and data ownership. A capability-centered boundary is more likely to produce something a team can explain, own, and operate without endless translation from technical structure back into business purpose.

    flowchart TD
	    A["Potential boundary"] --> B{"Centered on a real business capability?"}
	    B -- Yes --> C["Check ownership, data, and workflow pressure"]
	    B -- No --> D["Likely technical split without enough meaning"]

Why Capability Is Usually the Best Starting Point

Capability is a strong heuristic because it aligns several things at once:

• a business outcome that matters to the organization
• a language that product, engineering, and operations can all recognize
• a likely ownership area for one team or tightly aligned group
• a natural place to define authoritative business decisions

It is easier to evaluate whether billing or checkout should be separate than whether invoice_table or customer_controller should be separate. The former talks about responsibility. The latter talks about implementation residue.

Capability Boundaries Are Stronger Than Layer Boundaries

Technical layers still matter inside a boundary. A service may have controllers, repositories, workflows, and event handlers. But those are internal implementation concerns. They rarely make good top-level service boundaries on their own.

A layer-based split often creates services that mostly forward calls, expose storage details, or fragment one workflow across several thin APIs. Capability-based boundaries are more likely to produce contracts shaped around business actions instead of internal plumbing.

Turning a Capability Into a Reviewable Candidate

A capability label is not enough. Teams should make the candidate explicit:

• what business decision happens here?
• what outcomes does this boundary own?
• what data is authoritative here?
• what does it explicitly not own?
• which team would operate it?

The example below is a useful first-pass capability card.

1capability: checkout
2purpose: Confirm intent to purchase and prepare an order for downstream financial and fulfillment work
3owns:
4  - checkout_session
5  - purchase_confirmation
6does_not_own:
7  - final payment settlement
8  - shipment execution
9team: commerce-checkout

What to notice:

• a capability boundary should describe decisions and outcomes, not just nouns
• does_not_own is often where weak boundaries become visible
• the card forces clarity before a team starts designing APIs

Common Mistakes

• using a broad business noun as a capability without checking whether it hides several unrelated concerns
• assuming one capability label automatically deserves its own service
• confusing a shared identifier with a shared responsibility
• forgetting to connect the capability to real ownership and operations

Capability-first design is strongest when it is the beginning of a review, not the end of one.

Design Review Question

A team proposes a customer service because customer-related data appears in onboarding, billing, support, loyalty, and identity. Is capability-based decomposition pointing toward one service here?

Usually no. The stronger answer is that customer is a broad business noun, not automatically one coherent capability. The review should separate the actual responsibilities before treating the label as a boundary.

Quiz Time