Skip to main content

Decomposition Heuristics: Business Capability, Subdomain, Noun/Verb

What This Concept Is​

Three practical lenses that help you propose service boundaries. Each one gives a slightly different answer, and their agreement (or disagreement) is information.

  1. Decompose by business capability. Ask the business: "what does the company do?" The answer is a hierarchy of capabilities (e.g., "acquire customers", "manage catalog", "fulfill orders", "process payments"). Each capability is a service candidate.
  2. Decompose by subdomain. From DDD: a domain is split into subdomains classified as core (your differentiator), supporting (needed but not differentiating), and generic (solved commodity). Each subdomain is a service candidate, with investment strategy varying by class.
  3. Decompose by noun/verb. For every major workflow, list the nouns (entities) and the verbs (operations). Services align naturally with verbs-and-their-owned-nouns, not with nouns alone.

The three lenses usually converge. When they disagree, the disagreement usually reveals a boundary you should re-draw or a context that is larger than one capability.

Why It Matters Here​

Engineers decomposing in isolation tend to produce entity services ("one service per table"), which is the anti-pattern covered in concept 06. Business-capability and subdomain lenses pull you toward behavior and responsibility. Noun/verb pulls you toward action. Used together, they converge on services that are cohesive around an outcome.

Concrete Example​

A simple online bookstore. Let's run all three lenses.

Lens 1: Business capability

  • Browse catalog
  • Manage inventory
  • Take orders
  • Process payments
  • Fulfill shipments
  • Manage customer accounts

Candidate services: one per capability, six services.

Lens 2: Subdomain classification

  • Core: Catalog (differentiating curation + recommendations), Fulfillment (differentiating speed).
  • Supporting: Orders, Customer Accounts.
  • Generic: Payments (use a provider), Email (use a provider), Auth (buy, don't build).

Core subdomains get the most engineering investment; generic subdomains are thin integration layers over vendors.

Lens 3: Noun/verb for the "place an order" workflow

  • Nouns: Customer, Cart, Order, Payment, Inventory, Shipment.
  • Verbs: add-to-cart, checkout, authorize-payment, capture-payment, reserve-stock, confirm-order, schedule-shipment.

Services group verbs and their owned nouns:

  • Catalog Service -- browse, search (owns Product-marketing-view).
  • Cart Service -- add-to-cart, update-cart (owns Cart).
  • Orders Service -- checkout, confirm-order (owns Order).
  • Payments Service -- authorize-payment, capture-payment (owns PaymentAttempt).
  • Inventory Service -- reserve-stock, release-stock (owns StockItem).
  • Fulfillment Service -- schedule-shipment, track-shipment (owns Shipment).

All three lenses agree on roughly the same six services, with clear owned data. That convergence is the strongest decomposition signal you will get.

Common Confusion / Misconception​

"Decomposing by noun means one service per table." That is the entity-service anti-pattern. A service owns its nouns and the verbs that act on them. If a noun has no verbs beyond CRUD, it usually does not deserve its own service; it should be embedded as a value inside another service.

Second confusion: treating the lenses as alternatives rather than cross-checks. You should apply all three. When they disagree, fix the decomposition, not the lens.

How To Use It​

  1. List the business capabilities in 5-10 lines.
  2. Classify each as core, supporting, or generic.
  3. For the 2-3 most critical workflows, list nouns and verbs.
  4. Propose services whose scope is one capability / subdomain and whose data ownership matches the nouns-owned-by-verbs analysis.
  5. For each service, write one sentence: "This service owns noun X and performs verbs A, B, C. It calls service Y for capability Z."

Check Yourself​

  1. Why does "decompose by capability" tend to produce better boundaries than "decompose by entity"?
  2. When the three lenses disagree, which one do you trust first and why?
  3. What is the difference between a "Payment Service" (verb-owning) and a "Payment Entity Service" (noun-only)?

Mini Drill or Application​

Apply all three lenses to a SaaS product you use. Produce:

  • 5-8 capabilities
  • each classified as core/supporting/generic
  • noun/verb breakdown for one workflow
  • a list of 4-6 candidate services with one-sentence responsibility each

15 minutes. Stop when you can name each service and its owned data.

How This Sits In The Module​

This concept feeds directly into the cluster-3 data-ownership rule (a service owns its nouns, full stop) and into concept 06, which names the common ways these lenses get abused.

When the Lenses Disagree: Diagnostic Patterns​

When the three lenses do not produce the same answer, the disagreement is itself a signal. Common patterns:

  • Capability lens says one service, noun/verb says two. Usually a sign that one capability owns two distinct aggregates with non-overlapping invariants. Example: "Manage orders" capability contains both Order (customer-facing) and FulfillmentPlan (warehouse-facing). The noun/verb analysis reveals the split. Promote to two services aligned to the deeper bounded contexts.
  • Subdomain lens says generic, capability lens says core. Usually the capability is actually supporting -- strategically important for delivery but not differentiating. Example: "checkout" in an e-commerce site is often core experience but the underlying "accept payment" is generic (use Stripe). Split: core wrapper + generic adapter.
  • Noun/verb produces a CRUD-only service. The business logic lives somewhere else (usually a BFF or an orchestrator). Either the entity is a value object inside a larger aggregate, or the verbs have not been identified. Return to the workflow and find them.

Disagreement is information; making the three lenses converge is the decomposition exercise.

Event Storming as a Lens Combiner​

Event Storming (Alberto Brandolini) is a collaborative technique that often converges all three lenses in one workshop:

  1. Whole group writes domain events on orange stickies, time-ordered left-to-right on a wall.
  2. Commands (blue) that trigger events are added next to them.
  3. Aggregates (yellow) that own the state change are clustered.
  4. Bounded contexts emerge as clusters of related events sharing language.
  5. Service candidates fall out naturally: one service per aggregate cluster, one capability per context, verbs-and-nouns populated from the timeline.

This is the single most efficient way to perform the three-lens exercise in a cross-functional room. Schedule 2-4 hours with engineers, product, and domain experts. The wall produced is the decomposition memo's raw input.

Check Yourself (Extended)​

  1. Your team produces three candidate services via the noun/verb lens, but the capability lens produces two. Which is more likely correct and why? (Answer: the capability lens usually wins because it tracks how the business asks for change; the extra noun/verb service is often an aggregate inside one of the two capabilities.)
  2. Why is "generic" subdomain classification a buying decision, not a building decision? (Answer: generic subdomains are solved commodities; the right action is to buy/adopt, not to invest engineering. Auth, payments, email are the classic examples.)

Read This Only If Stuck​

Local chunks​

External canonical references​

Depth Path​

  • Sam Newman, Building Microservices (2nd ed.) chapter on "Identifying Microservice Boundaries" uses all three lenses with more examples.
  • Eric Evans, Domain-Driven Design, Part IV (Strategic Design) -- the canonical subdomain classification text.
  • Vaughn Vernon, Implementing Domain-Driven Design, chapters 2-3 -- applies strategic design to modern service-oriented systems.