⌘ The Architecture Reference

Ddd strategic · Domain-Driven Design · Intermediate

Bounded Contexts

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

Ddd strategic Intermediate ⏱ 4 min read Complete

🧭 Analogy

A tomato is a fruit in botany, a vegetable in the kitchen and tax law, and “a feedback mechanism” to a stage performer. Nobody is wrong — each field has its own area of meaning. A bounded context is exactly that: the boundary inside which a word means one specific thing.

The tension this solves

The ubiquitous language must be consistent (one meaning per term), yet at organizational scale different experts hold inconsistent mental models of the same concept. In a telemarketing company, lead means to marketing a notification that someone is interested (contact details), but to sales a complex, long-running entity spanning the whole sales lifecycle. A single enterprise-wide model trying to satisfy both becomes a wall-spanning ERD “suitable for everything but effective for nothing.”

DDD’s answer is the bounded context: split the language into multiple smaller languages, each with an explicit boundary inside which it stays consistent.

graph TD
L["Term: 'Lead'"] --> M["Marketing context<br/>Lead = prospect's contact details"]
L --> S["Sales context<br/>Lead = full sales-process entity"]
M --> MT["Owned by Marketing team"]
S --> ST["Owned by Sales team"]

Two tempting alternatives both fail: a single enterprise model (the giant ERD), and prefixing terms (marketing lead / sales lead) — which adds cognitive load and diverges from how people actually speak.

A context is three boundaries at once

  • Model boundary — A model cannot exist without a boundary, or it expands until it becomes a copy of the real world. The context defines the applicability of a ubiquitous language: it is ubiquitous only within its bounded context, not universally.
  • Physical boundary — Each context is an individual service/project, implemented, evolved, and versioned independently, possibly with its own tech stack.
  • Ownership boundary — Exactly one team maintains a context. The relationship is one-directional: a team may own several contexts, but two teams never share one.
graph TD
BC["One bounded context"] --> MB["Model boundary<br/>(one consistent language)"]
BC --> PB["Physical boundary<br/>(own service, stack, lifecycle)"]
BC --> OB["Ownership boundary<br/>(exactly one team)"]

Discovered vs designed

This is the key distinction: subdomains are discovered (they come from business strategy — you analyze to identify them), while bounded contexts are designed (you decide how to divide the domain). A context may contain several subdomains as logical modules inside it.

Sizing a bounded context

Models should be useful, not necessarily big or small. A wider boundary makes the language harder to keep consistent; smaller boundaries add integration overhead. Extract finer-grained contexts to form new teams, to address nonfunctional requirements (decoupling lifecycles), or to scale independently.

Keep coherent use cases together

Consistency identifies the widest possible boundary — you may decompose further but never wider. The pitfall is splitting coherent functionality that operates on the same data across contexts, which creates chatty, fragile integrations. A one-to-one subdomain-to-context mapping is fine sometimes but not mandatory; forcing it forbids using multiple models of the same subdomain for different problems.

See also

When to use it — and when not

✅ Reach for it when

  • When the same term carries conflicting meanings across departments or experts.
  • When you need to form a new team, decouple lifecycles, or scale a part independently.
  • Whenever an enterprise-wide model is becoming a 'jack of all trades, master of none'.

⛔ Think twice when

  • Don't fragment coherent use cases operating on the same data across contexts.
  • Don't force a one-to-one subdomain-to-context mapping when multiple models of one subdomain are useful.
  • Don't start with the smallest possible contexts when the domain is poorly understood.
ddd-strategicUbiquitous Language

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

ddd-strategicContext Mapping and Integration Patterns

The six patterns for integrating bounded contexts — partnership, shared kernel, conformist, ACL, OHS, separate ways — and the map that charts them.

ddd-strategicBusiness Domains and Subdomains

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

Check your understanding

Score: 0 / 4

1. What is a bounded context?

A bounded context is the consistency boundary of a ubiquitous language: within it every term has a single meaning, while across contexts the same term may differ.

2. How do subdomains differ from bounded contexts?

Subdomains are defined by business strategy and identified through analysis; bounded contexts are a strategic design decision about how to divide the domain.

3. What is the ownership rule for a bounded context?

Ownership is one-directional: a context has one owning team, but a team may own several contexts. This forces explicit integration contracts — 'good fences make good neighbors'.

4. Consistency of the language identifies which boundary?

Consistency sets the widest valid boundary; you can split a context into smaller ones, but you should never make it wider than where the language stays consistent.

Comments

Sign in with GitHub to join the discussion.