Bounded Context
- Categories
- Architecture
An explicit boundary within which a single domain model applies and its terms have one precise meaning. Outside the boundary the same word may mean something different, modeled differently. Bounded contexts make the limits of a model deliberate: each context owns its model and language, and integration between contexts is handled explicitly rather than by pretending one universal model covers everything.
Why it Matters
A single model that tries to cover an entire business inevitably blurs, because the same term ("customer," "order") means different things to different parts of the organization. Forcing one model creates a tangle where every change ripples everywhere. Drawing context boundaries lets each part keep a clean, internally consistent model, contains the blast radius of change, and turns implicit accidental overlaps into explicit, managed integrations.
Signals
- The same term means different things in different parts of the system, and each context models it its own way.
- A model stays consistent and changes locally within its context.
- Integration between contexts is explicit (translation, published interfaces), not shared internals. Anti-signal: one giant model everyone fights over, where a change for one team breaks another.
Benefits
Internally consistent models, localized change, contained complexity, and a clear map of where translation between models is actually needed.
Risks
Drawing boundaries along technical layers or org convenience instead of real differences in meaning; too many tiny contexts that multiply integration cost; leaking one context's model into another, which an anti-corruption layer exists to prevent.
Tensions
More contexts mean cleaner models but more integration and translation overhead; fewer mean less integration but blurred models. The boundary should follow genuine differences in meaning and ownership, the same judgment as choosing any modular boundary or fracture plane.
Examples
"Account" in billing (a balance) versus in identity (a login) modeled as two contexts with explicit translation between them, instead of one overloaded Account shared across both.