Subdomains describe the problem space and bounded contexts describe the solution space in Domain-Driven Design. When a team maps subdomains onto bounded contexts, should the result usually be a clean one-to-one match, and what goes wrong when teams assume it must be?

## The two spaces Strategic design in DDD operates in two spaces. | Layer | What it yields | How | |---|---|---| | **Problem-space decomposition** | produces subdomains: partitioning everything the business needs to do into core, supporting, and generic buckets based on competitive value | arrived at by talking to domain experts and looking at the business model, not the org chart or codebase | | **Solution-space decomposition** | produces bounded contexts: boundaries within the system being built, each with its own consistent model and ubiquitous language | arrived at by looking at where language and models diverge and where team or deployment boundaries make sense | The mapping step is the bridge: for each subdomain, deciding which bounded context or contexts will implement it. ## Keeping the layers apart Why keep the two layers distinct rather than conflating them: if you let implementation convenience dictate strategic classification, you risk under-investing in a core subdomain because it happens to be awkward to isolate technically, or over-splitting a simple supporting subdomain into multiple services just because two teams happen to touch it. Keeping the layers separate also lets the business classification stay stable even as the technical architecture is refactored — a core subdomain can be re-platformed from a monolith module into several services without its strategic importance changing at all. ## What forcing a clean match costs Trade-offs of forcing one-to-one versus allowing flexible mapping: - **Forcing one-to-one gives conceptual simplicity** — one subdomain, one team, one service is easy to reason about and staff, and it's a fine default for small or medium systems. It breaks down at scale: a genuinely large core subdomain accumulates enough internal complexity and enough distinct sub-languages that cramming it into one bounded context produces a context so large its own ubiquitous language starts to fracture internally — the classic symptom of a context that needs splitting. - **Allowing multiple bounded contexts per subdomain** fixes that but costs coordination overhead — more service boundaries mean more integration contracts and more places a core business-logic change has to touch. - **Conversely, allowing multiple subdomains to share one context** saves overhead when complexity is genuinely low, but risks that context becoming a dumping ground that later needs disentangling once one of the subdomains grows. ## Three ways the mapping goes wrong Failure modes: 1. **A 'god context masquerading as the core subdomain'** occurs when a team declares 'checkout is our core subdomain, so it's one bounded context,' and years later that one service owns payment orchestration, inventory reservation, promotions, and fraud scoring, each with genuinely different models and change cadences, crammed together because nobody revisited the mapping as internal complexity grew; the symptom is a service where every deploy risks unrelated regressions and the team can't agree what 'order' even means internally anymore. 2. **Premature fragmentation is the opposite failure:** a small team splits a low-complexity supporting subdomain into several microservices before there's any team-scaling or independent-deploy reason to pay that distributed-systems tax; the symptom is constant cross-service calls and deployment coordination for something simple enough to be one module. 3. **A third failure is drawing context boundaries along org-chart lines** instead of subdomain/language boundaries — two teams each 'own' half of what should be one bounded context because of historical reporting structure, causing the same business concept to be modeled inconsistently across the split. ## Music recommendation, worked through Worked scenario: at a music-streaming company, 'music recommendation' is core. Early on it might live inside one bounded context. As the subdomain matures, it's common for that single subdomain to be realized by several bounded contexts — one for candidate generation, one for ranking and personalization, one for experiment orchestration — each with its own model and release cadence, all still serving the one core subdomain. Meanwhile something like content-licensing metadata (supporting) might share a single bounded context with adjacent catalog-management concerns, because splitting it further isn't yet justified by team size or divergent language. **The lesson:** subdomain classification tells you where to invest; bounded-context boundaries are drawn separately, based on model and language cohesion and team-scaling needs, and the two are re-evaluated on different triggers.