Bounded Context
Also known as: DDD bounded context
A bounded context is an explicit boundary within which a domain model and its terms have one consistent meaning. Outside it, the same word may mean something different — and that is expected. It is the primary tool for deciding where a system should split.
Last reviewed · Part of the Architecture Glossary
In practice
The test is linguistic and it is surprisingly reliable: find a noun the business uses differently in two conversations, and you have found a boundary.
"Customer" in an e-commerce business:
| Context | What "customer" means |
|---|---|
| Sales | A lead with a pipeline stage and an owner |
| Billing | A legal entity with a tax ID and payment terms |
| Support | A person with a ticket history and a contact preference |
| Shipping | An address with delivery constraints |
The wrong response is one Customer table with 60 nullable columns that four teams fight over. The right response is four models with their own storage, linked by a shared identifier, translating at the edges via an anti-corruption layer.
Contexts are also the natural service boundary. A service that does not own a full context ends up making synchronous calls to complete every operation — that is a distributed monolith, and it is worse than the monolith it replaced.
When it matters
Decomposing a monolith, drawing service boundaries, resolving the recurring argument about which team owns a shared table.
Common mistake
Splitting by technical layer or by entity — user-service, order-service, notification-service — instead of by language boundary. Entity-per-service guarantees that every business operation spans several services, which is exactly the coupling the split was meant to remove.
See also
- Anti-Corruption LayerAn anti-corruption layer is a translation boundary that converts between your domain model and an external or legacy one, so foreign concepts and naming do not leak inward.
- CouplingCoupling is the degree to which one component depends on the internals of another, measured by how much of it must change when the other changes.
- Conway's LawConway's Law observes that a system's structure mirrors the communication structure of the organisation that builds it.
- Saga PatternA saga replaces a distributed ACID transaction with a sequence of local transactions, each publishing an event that triggers the next.