Bounded Context
A bounded context is an explicit boundary within which a domain model and its language are consistent, preventing one overloaded word from meaning several incompatible things.
Definition
A bounded context is a boundary that delimits where a particular domain model applies and where its terms have a single, precise meaning, separating models that would otherwise conflict.
Context and scope
It is used to partition a large domain so teams can evolve their models independently without a global, contradictory glossary.
Common misconceptions
- a bounded context equals one deployable service
- the same concept must have one shared representation everywhere
Anti-patterns
- sharing a single large domain model across every team
- allowing one term to carry several meanings in the same model
Related concepts
Authoritative source
Definition
A bounded context is a boundary that delimits where a particular domain model applies and where its terms have a single, precise meaning, separating models that would otherwise conflict.
It is used to partition a large domain so teams can evolve their models independently without a global, contradictory glossary. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The same word can legitimately mean different things in different contexts, so a policy in one context is not the same object as a policy in another, and modelling them together creates contradictions.
Contexts relate through explicit mappings rather than a shared class, so translating at the boundary preserves each model’s integrity.
Trade-offs and alternatives
A context is a model boundary, not a deployment unit, so several contexts may live in one service or a single context may span several. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that a bounded context equals one deployable service. Another is that the same concept must have one shared representation everywhere. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to sharing a single large domain model across every team and to allowing one term to carry several meanings in the same model. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Aggregate Root, Repository Pattern, Unit of Work.