Subdomain
Classification describes business importance and differentiation, not automatically a software module or team.
- CorePrimary differentiation.
- SupportingRequired by the business.
- GenericCommonly solved problem.
Context
Why this is important
Distinguish subdomains by business importance and align architecture effort.
Strategic DDD and collaboration around business models.
Subdomains by business value
The shop remains a modular monolith with seven business modules and a shared deployment.
This is how you read the picture
- Core Strategic investment
- Supporting Targeted support
- Generic Assess standard solution
| Type | Business role | Architecture implication |
|---|---|---|
| Core | Differentiates the offer | Invest in deliberate modelling |
| Supporting | Enables core business | Integrate appropriately |
| Generic | Common capability | Consider standard solution |
Benefits & limitations
Helps if:
- The strategic importance of a business area must inform architecture and investment decisions.
- Different areas require different modelling depth or sourcing strategies.
Boundaries
- Core, Supporting and Generic are strategic assessments, not permanent technical categories.
- A subdomain need not map to a separate deployment, team or Bounded Context.
In practice
- Describe the business goal, customer value, and relevant capabilities before proposing software boundaries. Justify the classification with traceable business goals rather than technical preferences.
- Classify the subdomain as Core, Supporting, or Generic and document the market or business assumption behind the assessment. Involve domain experts who understand competition and operational needs.
- Use the classification to prioritize modelling depth and investment. Reassess it when the offering, differentiation, or available standard solutions change materially.
Read the detailed explanation
The Core Domain is where the business pursues its primary differentiation. Supporting Subdomains are needed for the business but create less competitive advantage of their own. Generic Subdomains solve common problems that may suit standard software or a shared platform. Classification follows business goals and can change with strategy or market conditions.
Subdomain analysis complements DDD and context boundaries: Domain-Driven Design frames the approach; Bounded Context describes a model and language boundary.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which subdomain drives primary differentiation?
View the solution with justification
The Core Domain.
ApplyingTransferred to a new situation
How would you classify a common accounting capability?
View the solution with justification
As Generic, if it creates no distinct differentiation.
EvaluateWeighing an alternative
Why does Core not automatically imply a separate service?
View the solution with justification
The classification describes business strategy; deployment depends on additional operational and team factors.
Explore further
These building blocks continue the thoughts of this page.
References
- Eric Evans · DDD Reference (opens in new tab)Primary reference on strategic DDD and domain modelling.
- Vaughn Vernon · Implementing Domain-Driven Design (opens in new tab)Practical book on strategic DDD and contexts.
- Domain-Driven Design Reference · Strategic Design (opens in new tab)Reference maintained by Eric Evans for shared DDD terminology.