The word "customer" means different things in sales, fulfilment and finance. How does that affect your service design?
Show the full answer Hide the answer
What is being tested
Whether you recognise the linguistic signal for a bounded context and know why the canonical-model alternative fails.
What the signal means
They are different concepts sharing a name.
- In sales, a customer is a prospect with a pipeline stage, an owner and a probability.
- In fulfilment, a customer is a delivery address, a set of preferences and a history of shipments.
- In finance, a customer is a payment method, a credit position and a billing entity.
Each has different attributes, different rules, different owners and different rates of change. They are related by an identifier and by nothing else.
The design that follows
Three bounded contexts, each with its own model, related by a shared customer identifier and by explicit translation where they meet.
Sales owns its model and can add a pipeline stage without consulting anyone. Fulfilment can change its address model. Finance can restructure its credit model. None of them blocks the others, which is precisely the property you are buying.
Where one context needs data from another, it either calls an interface or maintains a local projection built from events — with translation at the boundary, which is an anti-corruption layer by another name.
Why the canonical model fails
The intuitive alternative — one enterprise-wide "Customer" — is the classic enterprise architecture failure:
- It must serve everyone, so it has sixty fields of which each consumer uses eight.
- Nobody can change it without coordinating with every consumer, so it freezes within a year.
- It serves nobody well, because the compromises required to satisfy three different meanings produce a model that matches none of them.
- It creates a coupling point through which every team's changes must pass.
The trade is real: separate models mean mapping code and eventual consistency between projections. That cost is visible and manageable. The canonical model's cost is invisible and unbounded.
How to find the boundaries in practice
Map the business events in sequence with domain experts and engineers in the room — 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.
That is far faster and more accurate than modelling data, and it produces boundaries derived from the domain rather than from the current database schema.
What a strong answer adds
The corroborating evidence: change correlation. Look at the last fifty changes — what consistently changes together belongs together. That is evidence about what the system actually is, rather than what anyone intended, and it frequently confirms or corrects the linguistic analysis.