Two teams building an e-commerce platform both use the word 'Order' but mean different things — one team's checkout service treats an Order as a cart snapshot awaiting payment, another team's warehouse-fulfillment service treats an Order as a pick list of physical items. How should the shared domain vocabulary be handled when the same word carries different meanings in different parts of the system?

## The language holds inside one boundary Ubiquitous language is only guaranteed to be consistent within a **bounded context** — a boundary (often aligned to a team, a service, or a subdomain) inside which a single model and a single vocabulary apply without contradiction. Outside that boundary, DDD explicitly expects language to diverge, because different parts of a business genuinely think about the same real-world thing differently. The mechanism for handling this is not to suppress the divergence but to make it visible and managed: teams draw a **context map**, a diagram or document that names each bounded context and describes the relationship and translation strategy at each place two contexts meet. For the checkout-versus-fulfillment example, the context map would show two contexts connected by an explicit integration point: | Context | Whose 'Order' means | |---|---| | **Checkout** | 'a priced, payment-pending snapshot of a cart' | | **Fulfillment** | 'a set of physical line items with locations and pick instructions' | ## Patterns applied at the integration point At that integration point, teams typically apply one of a few well-known patterns. - **An anti-corruption layer (ACL)** is a translation module owned by the downstream context that converts the upstream context's model into its own local vocabulary and shape before anything crosses the boundary — so Fulfillment never directly consumes Checkout's `Order` object; it consumes a `FulfillmentOrder` that its own ACL constructs from whatever Checkout sends. - **Alternatively, a published language or shared kernel** — teams can agree on one for the narrow slice of concepts they truly need to agree on (e.g., a shared `OrderId` type and a small set of fields), while keeping everything else local and independent. The point of all these patterns is the same: **never let one team's internal model leak untranslated into another team's context**, because that silently welds two models together that were never designed to be one. ## Why one universal model is a design failure The reason this exists is that forcing one universal model onto a whole organization is a design failure, not a design win. Early or overambitious DDD adoption often tries to build 'the one true `Order` class' shared across every service, reasoning that consistency reduces confusion. In practice this produces an anemic, compromise model that satisfies no team's actual needs — Checkout needs fields Fulfillment doesn't care about and vice versa, and every change to the shared model requires cross-team negotiation and coordinated deployment, which kills velocity. Recognizing that 'Order' legitimately means two things is what lets each team optimize its own model for its own concerns without waiting on the other. ## The trade-off The trade-off is real **integration cost**: - translation code has to be written and maintained, - data sometimes has to be duplicated or eventually-consistent across contexts (e.g., Fulfillment keeps its own copy of order data rather than querying Checkout's database live), - new engineers have to learn that the same English word means different things depending on which service they're reading. Teams that skip this discipline get a false sense of savings up front and pay it back later when a schema change in one context silently breaks another context that was reading its raw model. ## Failure modes Failure modes are easy to spot in production. 1. **The most common is 'shared database, no translation'**: two services read and write the same `Order` table directly, so a schema change made for Checkout's needs (e.g., adding a payment-retry field) silently breaks a report or process in Fulfillment that assumed the old shape — an implicit, undocumented coupling caused by skipping the ACL. 2. **Another failure mode is a context map that was drawn once and never updated**, so new integrations get built ad hoc without anyone deciding whether they need translation, and the number of untranslated cross-context dependencies grows until nobody can change either service safely. 3. **A third is over-applying translation everywhere**, even between two sub-teams that genuinely share one small subdomain, which adds needless boilerplate — the skill is judging when contexts are truly semantically different versus just organizationally separate. ## Sales versus Support, the classic case A concrete real-world pattern is the classic DDD 'Sales' versus 'Support' example: | Bounded context | What a 'Customer' is | |---|---| | **Sales** | a lead with a sales-pipeline stage and quota attribution | | **Support** | an account with open tickets and an SLA tier | Both are legitimately called 'Customer', both are correct within their own context, and a CRM integration layer translates between the two — pulling a sales lead's contact info into a support account record rather than trying to merge them into one shared `Customer` class.