Key Principle
Subdomains decompose a business domain into three categories that determine where to concentrate scarce modeling effort and talent:
- Core Domain: Where the organization must excel — the competitive differentiator. Requires deep DDD collaboration because the model IS the competitive advantage.
- Supporting Subdomain: Custom but non-differentiating. Exists to serve the Core Domain; design quality need only be "good enough."
- Generic Subdomain: Buy or outsource. Commodity functionality (identity management, payments, email).
The optimal composition is one Subdomain per Bounded Context. When organizational constraints force multiple Subdomains into one Bounded Context, segregate via Modules (packages/namespaces) to preserve linguistic boundaries.
Why This Matters
Misclassification drives two opposite resource allocation failures: classifying Generic as Core causes elite developers to build commodity software, while classifying Core as Generic causes the organization's differentiator to be outsourced or bought off-the-shelf. Without explicit classification, teams spread modeling effort uniformly — the Core Domain gets the same shallow treatment as everything else.
"Since your organization can't be distinguished in everything that it does, your Core Domain demarcates where it must excel." (Chapter 3)
Good Examples
Legacy reasoning tool: Even in a Big Ball of Mud where no clean boundaries exist, drawing conceptual Subdomain boundaries (dashed lines around logical areas) enables: (1) identifying which tangled parts contain Core Domain logic worth extracting, and (2) planning incremental migration by treating each identified Subdomain as a future Bounded Context. Without this, legacy modernization becomes all-or-nothing, which means it never happens. (Chapter 3)
Investment prioritization: Core Domains get the best developers and deepest DDD practices. Supporting Subdomains get competent implementation without heavy modeling investment. Generic Subdomains get purchased solutions. Each classification directly determines team staffing and budget allocation. (Chapter 3)
Counterpoints
The ego trap: Teams rebuild generic capabilities (identity management, payments) because building feels productive, when purchasing would free capacity for the Core Domain. This is an ego-driven resource misallocation. (Chapter 3)
Over-investment in Supporting: Because Supporting Subdomains require custom code, teams sometimes apply Core-level modeling effort to them. This starves the Core Domain of the attention it needs to deliver competitive advantage. (Chapter 3)
Key Quotes
"Since your organization can't be distinguished in everything that it does, your Core Domain demarcates where it must excel." — Vaughn Vernon, Chapter 3
Rules of Thumb
- Core Domains get the best developers; Generic Subdomains get purchased solutions
- If you're building something you could buy, question whether it's truly Core
- Use Subdomain boundaries on legacy systems to plan incremental extraction
- Module segregation is the fallback when 1:1 Subdomain-to-Context mapping isn't achievable
Related References
- Bounded Contexts and Ubiquitous Language - Solution-space boundaries that map to Subdomains
- Context Mapping Relationships - How Subdomains/Contexts integrate
- Anti-Patterns and Failure Modes - Big Ball of Mud as the legacy starting point