Bounded Contexts

The Same Word, Different Worlds

 "Order" means different things in different domains:

 SALES context:      {items, prices, discounts, customer intent}
 FULFILLMENT:        {packages, weights, warehouse, carrier}
 BILLING:            {amounts, tax lines, payment status}
 SUPPORT:            {history, notes, sentiment, entitlements}

 forcing ONE Order model on all four:
 - giant schema with nullable everything
 - every team's change ripples into strangers' code
 - semantic arguments disguised as tech debates

 BOUNDED CONTEXT: a boundary INSIDE which a model and its
 language are consistent. across boundaries: explicit
 translation (not shared models).

Context Mapping

 draw the contexts and their relationships:

 [Sales]──OrderPlaced──►[Billing]     event-based handoff
 [Sales]──Order DTO────►[Fulfillment] translated payload
 [Billing]─no direct link─[Fulfillment] (independence ✓)

 patterns for the seams:
 SHARED KERNEL:   genuinely common model subset (rarely;
                  small and stable only)
 CUSTOMER/SUPPLIER: upstream serves downstream's needs
                  via negotiated contract
 ANTI-CORRUPTION LAYER: translator shielding your model
                  from external/legacy shapes ← the workhorse
 
 each service = one context (+ its ACLs at edges).

The Practical Payoffs

 □ MODELS STAY SMALL AND TRUE: fulfillment's Order holds
   packages, not discount logic. no null-swamp fields.
 □ TEAMS OWN LANGUAGE: no cross-team schema committees;
   contracts at seams instead
 □ CHANGE LOCALIZES: billing's new tax model touches billing.
   monolith-model changes touch everyone by default.
 □ ONBOARDING ACCELERATES: learn ONE context's world,
   not the whole enterprise ontology

Spotting Missing Context Boundaries

Symptom	Hidden contexts colliding
Fields used differently per caller	two models sharing a table
”Temporary” flags accumulating	semantics diverging silently
Debates about what a field MEANS	languages not actually shared
Copy-on-write of entities between teams	boundary exists informally

 the flag smell deserves its own warning:
 status: "SHIPPED_BUT_NOT_REALLY_FOR_BILLING" — that name
 is two bounded contexts screaming through one boolean.
 split them properly.

Interview Framing

“Teams keep fighting over the user table schema” scored diagnosis: recognize colliding bounded contexts sharing one model, propose context split with per-context models + translation at seams (ACL named), event-based integration where possible, single-meaning test as the verification. This question appears constantly because context-awareness separates domain thinkers from schema typists — answer in DDD vocabulary without drowning in it.