Domain Boundaries from the Business
Deriving service boundaries from the language and decisions of the business, rather than from data structure or team structure.
Definition
A bounded context is a boundary within which a model and its language are consistent. Its defining property is that the same word means different things in different contexts, and pretending otherwise produces a model that serves nobody.
The linguistic test, which is the most reliable one
Listen for a word that changes meaning. "Customer" in sales is a prospect with a pipeline stage; in fulfilment it is a delivery address and a set of preferences; in support it is an entitlement history; in finance it is a payment method and a credit position.
These are different concepts sharing a name. Forcing them into one "Customer" service produces an entity with sixty fields, of which each consumer uses eight, and which cannot be changed by anyone without coordinating with everyone.
Each is its own bounded context with its own model, related by an identifier and by explicit translation at the boundary.
The other signals
- Different decision-makers. If two areas have different people accountable for the rules, they are different contexts.
- Different rates of change. Pricing rules change weekly; the ledger changes yearly.
- Different consistency requirements. One needs transactional integrity; another tolerates staleness.
- Change correlation. Look at the last fifty changes: what consistently changes together belongs together. This is evidence about what the system actually is, rather than what someone intended.
Why business-derived boundaries beat the alternatives
Data-derived boundaries produce entity services — a Customer Service, an Order Service — none of which can complete a business action alone, so every feature touches several.
Team-derived boundaries encode the current org chart, which will change.
Business-derived boundaries follow the shape of the domain, which is the most stable thing available and the thing the systems exist to serve.
The practical technique
Get the domain experts and engineers in a room and map the business events in sequence — what happens, in what order, triggered by what. The clusters of events that belong together, and the points where the language changes, are the context boundaries. This is far faster and more accurate than modelling data.
Failure scenarios
- One canonical model for the whole enterprise, which is the classic failure — it serves every consumer badly and can be changed by nobody.
- Boundaries drawn on nouns, producing entity services.
- Ignoring the language signal, so a word with three meanings gets one model.
- Boundaries drawn without domain experts, so they reflect the data model rather than the domain.
Interview question
"The word 'customer' means different things in sales, fulfilment and finance. How does that affect your service design?"