Oh My Learning

Bounded contexts and explicit model boundaries

ddd-evans/14 senior drafted · 8 min read

Domain-Driven Design (Eric Evans), Part IV, Chapter 14

Prerequisites ddd-evans/01 ddd-evans/02 ddd-evans/13

Bounded contexts and explicit model boundaries#

TL;DR#

A bounded context is an explicit boundary within which a single model and its ubiquitous language apply consistently; outside that boundary, the same word can — and often should — mean something different, and pretending one universal model can serve an entire large organization produces a model so watered-down and contradiction-laden that it serves nobody well.

The idea#

ddd-evans/01 argued for one precise, shared vocabulary — but that guidance was implicitly scoped to a team working on one cohesive part of a system. Scale up to a large organization, and you hit a hard limit: different departments genuinely mean different things by the same word, not out of sloppiness, but because their concerns are genuinely different. Sales cares about a "Customer" as a prospect with a sales history and assigned rep; billing cares about a "Customer" as a legal billing entity with payment terms and tax status; support cares about a "Customer" as a person with a ticket history and entitlement level. Forcing one Customer class to satisfy all three departments produces either a bloated object trying to be everything to everyone, or a watered-down lowest-common-denominator model that's precise about nothing.

A bounded context accepts this reality instead of fighting it: draw an explicit boundary (usually aligned with a team, a subsystem, or a service) inside which one model and one ubiquitous language hold consistently — and outside of which you make no claim that the same words mean the same thing. The Customer in the sales context and the Customer in the billing context are different classes, possibly with different attributes, different invariants, and definitely not assumed interchangeable — any translation between them is made deliberate and explicit (ddd-evans/15), never implicit and accidental.

How it works#

Recognizing where a boundary is needed#

The signal is the same one from ddd-evans/01: when knowledge crunching surfaces that two groups use the same term with genuinely different meaning, and reconciling them into one shared definition would either lose information one group needs or add complexity the other group doesn't want, that's a sign a bounded context split is warranted rather than continued negotiation toward a single universal model.

Worked example — "Product" in three different contexts: - Catalog context: Product has a description, images, category, marketing copy — optimized for browsing and search. - Inventory context: Product (or perhaps not even called "Product" here — see below) has stock levels, warehouse locations, reorder thresholds — optimized for supply-chain operations. - Pricing context: Product has price tiers, discount eligibility rules, currency-specific pricing — optimized for the pricing engine.

Trying to merge these into one Product class produces a single sprawling object that every context has to load in full even when it only cares about a fraction of its fields, whose invariants from one concern (pricing rules) have nothing to do with another (warehouse location), and whose "reason to change" (Martin's single-responsibility framing) is actually three unrelated reasons braided together. Each context should have its own Product model, shaped for its own concerns, with an explicit context map (ddd-evans/15) describing how the same real-world product is identified and reconciled across contexts (typically via a shared ProductId, translated at each boundary).

Bounded contexts and team/deployment boundaries#

In practice, a bounded context often — though not necessarily — aligns with a team boundary and a deployment boundary (a microservice, a separately deployable module). This is not a coincidence: Conway's Law observes that system structure tends to mirror communication structure, and DDD's strategic design leans into this rather than fighting it — give each context to one team, let that team own its model and language fully, and require explicit, deliberate integration (not shared database tables, not shared classes) at the seams between contexts. This directly generalizes ddd-evans/07's module-boundary discipline up to the organizational level: a module boundary that also implies a distinct language and, often, separate team ownership is a strong candidate to become a full bounded context, potentially its own deployable service.

What must NOT cross a bounded context boundary#

  • Shared mutable database tables — two contexts reading and writing the same table means they're not actually bounded from each other at all; a schema change on behalf of one context's needs can silently break the other.
  • Shared domain classes imported directly — importing another context's Customer class and using it directly reintroduces the "one universal model" problem this pattern exists to avoid; if you need data from another context, it must come through an explicit integration point (an API, an event), translated into your own context's terms.
  • Implicit vocabulary assumptions — using the word "Customer" across two teams' conversations without either side confirming which context's definition is meant is exactly the ambiguity a bounded context boundary is supposed to force into the open.

Worked example: a boundary drawn too late#

A team built a single monolithic Customer class shared across sales, billing, and support features from day one, because at small scale the differences seemed minor and unifying felt simpler. Over eighteen months, the class accumulated fields relevant to each concern, its constructor grew unmanageable, and a change made for billing purposes (adding a required tax-ID field) broke sales-flow signups that had no tax ID at time of prospect creation, because both flows unknowingly shared the same invariant-enforcing constructor. Retrofitting a bounded-context split after this much entanglement required a careful, staged migration (see ddd-evans/16 for large-scale-structure-level thinking about this kind of evolution) — considerably more expensive than recognizing the boundary earlier, when the sales/billing distinction in vocabulary first started to feel forced during knowledge crunching.

Pros#

  • Lets each part of a large system have a precise, internally consistent model instead of a compromised, watered-down universal one.
  • Aligns naturally with team ownership and deployment boundaries, reducing cross-team coordination overhead for changes local to one context.
  • Makes integration points explicit and deliberate (via context maps, ddd-evans/15) instead of accidental and fragile.

Cons#

  • Introduces real translation overhead at every boundary — data crossing from one context to another must be explicitly mapped, which is extra code and extra things that can drift out of sync if not maintained carefully.
  • Drawing boundaries too early, before the domain is well understood, risks boundaries that don't actually match where the real complexity and language differences live — costly to redraw later.
  • Requires organizational buy-in (team structure, ownership clarity) that a purely technical team can't unilaterally impose; misalignment between intended bounded contexts and actual team/reporting structure creates friction (a real-world instance of Conway's Law working against the design rather than for it).

Alternatives#

  • One universal model across the whole organization — the default a team falls into without deliberate boundary-drawing; simpler to reason about at small scale, but as this lesson argues, it collapses under real cross-department vocabulary differences once the organization grows past a single cohesive team.
  • Shared database schema as the integration mechanism — instead of explicit bounded contexts with deliberate translation at the seams, let every team read and write the same tables directly; far cheaper to set up initially, but reintroduces exactly the hidden coupling and accidental-shared-model problems this lesson warns against, since a schema change made for one team's needs can silently break another's assumptions.
  • Microservices without model boundaries — splitting a system into many small deployable services is sometimes conflated with bounded-context design, but a service boundary alone doesn't guarantee a distinct, internally consistent model and language; without deliberate attention to this lesson's concerns, a "microservices" system can still suffer from one implicit universal model smeared across many deployments. See implementing-ddd for a more service-boundary-focused treatment of this distinction.

When to use it#

Draw an explicit bounded context wherever knowledge crunching (ddd-evans/01) reveals a genuine, sustained difference in vocabulary or model needs between groups — most commonly at department boundaries in a large organization, or wherever a single system has grown large enough that one shared model has become a bottleneck or a source of unrelated-concerns entanglement.

When NOT to use it#

For a small system with one team and no real vocabulary conflicts, imposing multiple bounded contexts with formal translation layers between them is pure overhead — a single, well-maintained ubiquitous language (ddd-evans/01) inside one context is sufficient and considerably simpler.

Key takeaways / mental model#

A bounded context is a promise of internal consistency, not universal consistency: "within this boundary, this word means exactly one thing, always" — and the corollary promise is that outside the boundary, you make no such claim, and any crossing requires deliberate, visible translation, never a silent shared assumption.

Self-check questions#

  1. In the Product example, why does merging catalog, inventory, and pricing concerns into one class violate more than just "clean code" principles — what domain-modeling problem does it specifically create?
  2. Why does the book treat bounded-context boundaries as often aligning with team boundaries, rather than treating that as a coincidence to work around?
  3. In the "boundary drawn too late" example, what specific failure (the tax-ID field breaking signups) illustrates the cost of not having drawn the boundary earlier?
  4. Name two things that must never cross a bounded context boundary directly, and explain what should happen instead when data does need to cross.

References#

  • Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans), Chapter 14: "Maintaining Model Integrity" (Bounded Context section).