Core Domain

Categories
Architecture
Sources
Domain-Driven Design (Eric Evans)

The part of the domain that gives the business its competitive advantage, distinguished from generic subdomains (solved problems anyone can buy or copy) and supporting subdomains (necessary but not differentiating). The strategic instruction is to spend the most modeling effort and the best people on the core, and to minimize, buy, or outsource the rest.

Why it Matters

Design effort is finite, and spreading it evenly wastes it on parts that do not differentiate the business while starving the part that does. Naming the core domain directs investment to where the return is highest, and gives a principled answer to what deserves a deep model and what should just be good enough.

Signals

  • The team can name the few capabilities that are the reason the business wins.
  • The best modeling effort concentrates there, while generic concerns use off-the-shelf solutions.
  • Anti-signal: every part is treated as equally important, which is the same as treating nothing as core.

Benefits

Design investment concentrated where it pays, less effort sunk into commodity capabilities, and a clear basis for build-versus-buy and for where complexity is worth carrying.

Risks

Misidentifying the core and investing deeply in something generic; the core shifts over time but the investment focus does not follow; treating everything as core.

Tensions

Focusing on the core means deliberately under-investing elsewhere, which is uncomfortable when the supporting parts still demand attention. And what counts as core can shift as the business and market change, so the judgment must be revisited rather than fixed once.

Examples

A logistics company investing its deepest model in routing optimization (its edge) while using a standard package for payroll; deciding not to build a bespoke auth system because identity is not where the business differentiates.