Two teams disagree about whether "reservation" and "booking" are one concept or two. What evidence settles it?
Show the full answer Hide the answer
The evidence
1. Does the word mean the same thing to both teams? If the front-end team's "booking" includes an unconfirmed cart and the finance team's includes only a settled transaction, those are different concepts sharing a name. That is the definition of a context boundary.
2. Do they change for the same reason, on the same authority? If reservation rules change when inventory policy changes and booking rules change when finance policy changes, they have different owners and different cadences.
3. Change history. Do modifications to one routinely require modifications to the other? Persistent co-change is evidence of one concept badly split. A year of independent change is evidence of two.
4. Is there a genuine invariant spanning both? If a change to both must be atomic, splitting them means a saga where a transaction would do — a strong argument for one context.
5. Different lifecycles. A reservation may exist and expire without ever becoming a booking; a booking persists after the reservation is consumed. Different lifecycles usually indicate different concepts.
The likely answer here
Two contexts with a relationship, and a translation between them. A reservation is a temporary claim on inventory with an expiry; a booking is a commercial agreement with a customer. They interact — a booking consumes a reservation — and their models are genuinely different.
Forcing one model on both produces a class with fields that are meaningless in half its uses, which is the characteristic symptom of a missing context boundary.
What to do with the boundary
Explicit translation at the seam. Each context has its own model, and mapping between them is deliberate code rather than a shared class. This is an anti-corruption layer, and it is what allows each context to evolve without the other's constraints.
The cost of getting it wrong in each direction
Split when they are one: a distributed transaction where a local one would do, eventual consistency where an invariant needs enforcing, and a chatty interface for what should be one operation.
Merged when they are two: a model serving neither well, teams blocked on each other's changes, and fields that are meaningless in half their uses.
Merging wrongly is cheaper to fix — splitting a module is more tractable than merging two services and their data — which argues for fewer boundaries when the evidence is genuinely ambiguous.