// Architecture Styles · 09
Bounded Context
A boundary inside which every term means exactly one thing.
How it fits together
- Sales context publishes / notifies Billing context (OrderPlaced)
- Sales context publishes / notifies Anti-corruption layer (OrderPlaced)
- Anti-corruption layer uses / calls Shipping context (translates)
- Billing context publishes / notifies Shipping context (InvoicePaid)
Spot it
- "Customer" means three things to three teams
- One entity with dozens of optional fields
- A change for sales breaks shipping
It costs
Data is duplicated and translated between contexts instead of shared.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
A Domain-Driven Design idea: a large domain cannot have one consistent model, so you split it into contexts, each with its own language and model. A Product in Catalog and a Product in Warehouse are different objects that share an ID.
Boundaries follow language and business capability, not database tables. One team per context helps, but too many tiny contexts cost as much as one giant one; start coarse and split when the language diverges.
Bounded contexts are the best guide for modules in a modular monolith and services in microservices. Contexts integrate through events, published APIs or an anti-corruption layer, which is the adapter pattern at system scale.
Ask for it
- ubiquitous language
- context map
- anti-corruption layer
- shared kernel
- upstream / downstream
Draw a context map for this domain: list the bounded contexts (Sales, Billing, Shipping), what "Order" means in each, which context is upstream, and where we need an anti-corruption layer so Shipping does not depend on the Sales model.