⌘ The Architecture Reference

Ddd strategic · Guide · Start here

Business Domains and Subdomains

Decompose what a company does into core, supporting, and generic subdomains — the analysis that drives every later design decision.

Ddd strategic Start here ⏱ 5 min read Complete

🧭 Analogy

A coffee chain sells coffee — but it also leases real estate, hires staff, runs payroll, and pays taxes. Only some of those make it better than the chain across the street. Domain analysis is figuring out which activities are your secret recipe and which are the same plumbing everyone has.

Domain and subdomains

A business domain is a company’s main area of activity — the service it provides to clients (FedEx → courier delivery; Starbucks → coffee). A company can span several domains (Amazon: retail and cloud) and change them over time (Nokia: wood → rubber → telecom → mobile).

A subdomain is a fine-grained area of business activity. No single subdomain makes a profitable company, but together they form the domain and are all necessary to compete. The central move of strategic DDD is to classify each subdomain into one of three types, because the type dictates how you should build it.

graph TD
D["Business Domain"] --> Core["Core subdomain<br/>differentiator"]
D --> Sup["Supporting subdomain<br/>necessary, no edge"]
D --> Gen["Generic subdomain<br/>solved by everyone"]
Core --> C1["High complexity + volatility<br/>Build in-house, best talent"]
Sup --> S1["Simple CRUD / ETL<br/>Build but cut corners / outsource"]
Gen --> G1["Already solved<br/>Buy or adopt off-the-shelf"]

The three types

  • Core subdomain — What the company does differently from competitors to gain an advantage: invention, optimization, know-how, or IP. Complex, highly volatile (work is never done), and the source of profit. It need not be technical (a jeweler’s designs). Build it in-house with your best engineers; never buy or outsource it. These are the interesting problems.
  • Generic subdomain — Something all companies do the same way (authentication, encryption, accounting). Complicated but already solved — battle-tested products exist. No competitive edge, so buy off-the-shelf or adopt open source. These are the solved problems.
  • Supporting subdomain — Supports the business but provides no advantage. Simple logic: CRUD data entry and ETL. Low barriers to entry, so build it in-house (no ready-made option fits) but cut corners with rapid frameworks; good work for junior talent or outsourcing. These are the obvious problems.
TypeAdvantageComplexityVolatilityImplementation
CoreYesHighHighIn-house
GenericNoHighLowBuy / adopt
SupportingNoLowLowIn-house / outsource

Distinguishing the types

Core vs supporting? Ask: “could this be a side business someone would pay for?” → core. Supporting vs generic? Ask: “would it be simpler and cheaper to hack my own than to integrate an external one?” → supporting. Evaluate the complexity of the business logic you must model: CRUD-like ⇒ supporting; intricate rules and invariants ⇒ core.

Distilling subdomains

Coarse-grained departments (org units) are a starting point, but drill into their inner workings to find finer subdomains of different types. A “customer service” department might contain a help desk and phone system (generic), shift management (supporting), and an incident-routing algorithm (core).

graph TD
CS["Customer Service dept<br/>(coarse org unit)"] --> HD["Help desk + phones<br/>(generic — buy)"]
CS --> SM["Shift management<br/>(supporting — build cheap)"]
CS --> IR["Incident-routing algorithm<br/>(core — best talent)"]
Distill core subdomains aggressively — they are the most important, volatile, and complex. Relax distillation for supporting and generic ones once it reveals no design-relevant insight. Stop when a subdomain is a coherent set of use cases over the same data.

Tactical patterns are not the strategy

Building a full, sophisticated domain model for a supporting subdomain — or worse, outsourcing a core one — wastes effort and surrenders advantage. The whole point of classification is to match implementation rigor to business value. See design heuristics and evolution.

Domain experts

Domain experts are the subject-matter authorities on the business — the people who came up with the requirements or who use the software. The domain knowledge belongs to them; engineers do not become experts but must understand them and use their terminology. They are the origin of all domain knowledge and the single biggest predictor of project success — which is why the next step is building a shared language with them.

See also

When to use it — and when not

✅ Reach for it when

  • Starting a project and deciding where to spend your best engineers and which parts to buy or outsource.
  • Justifying build-vs-buy choices to stakeholders with a strategic rationale.
  • Sanity-checking that the implementation effort on a component matches its business value.
  • Distilling a coarse-grained department into the finer subdomains hiding inside it.
  • Re-assessing a component when the pain of changing it suggests its type has shifted.

⛔ Think twice when

  • When you have not yet talked to domain experts — subdomain types come from business strategy, not a guess.
  • As a one-time, frozen classification — subdomains migrate between types as the business changes.
  • Drilling endlessly into generic or supporting subdomains that reveal no design-relevant insight.
  • Classifying at the wrong granularity — judge the type at the level relevant to the software, not the business slogan.
ddd-strategicUbiquitous Language

Cultivate one shared, consistent language for the business domain — DDD's cornerstone practice and its single biggest predictor of success.

ddd-strategicBounded Contexts

Divide the ubiquitous language into smaller, internally consistent models — each its own model, physical, and ownership boundary.

ddd-applicationDesign Heuristics and Evolving Design

Answer DDD's perennial 'it depends' with a decision tree driven by subdomain type — then evolve those decisions as the business changes.

Check your understanding

Score: 0 / 5

1. Which subdomain type provides competitive advantage and should be built in-house?

Core subdomains are what a company does differently from competitors; they are complex, volatile, and must be built in-house with your best talent — never bought or outsourced.

2. Authentication and encryption are best treated as which type?

Generic subdomains are hard but solved the same way by everyone; battle-tested off-the-shelf implementations exist and give no competitive edge.

3. What is the rule of thumb for a subdomain's natural boundary?

A subdomain is technically a set of interrelated, coherent use cases involving the same actor and a closely related set of data — that tells you when to stop distilling.

4. A supposed 'supporting' subdomain that suddenly needs complex rules and changes constantly is probably...

Growing complexity and volatility in a 'simple' subdomain is the classic symptom of a supporting-to-core transition; the pain of change is the diagnostic signal.

5. Which is a genuine example of a generic-to-core subdomain transition?

Generic-to-core happens when a company builds in-house to outperform a commodity solution and turns it into an advantage — Amazon's infrastructure becoming AWS is the archetype.

Comments

Sign in with GitHub to join the discussion.