Why the language is per bounded context

A subdomain names the problem, a bounded context names the solution

A subdomain is a part of the problem. It marks an area of the business, such as sales or billing, before anyone designs a system for it. A bounded context is a part of the solution. It marks a model, and that model draws a boundary around the terms it uses.

One subdomain can hold two models at once, one for each bounded context that touches it. Two models in one area carry two meanings for one word. A glossary of that subdomain therefore needs two entries under one word. Nothing in the entry tells a reader which of the two applies to the code in front of him.

The boundary is the largest area in which a word keeps one meaning

Domain-Driven Design defines a bounded context as the boundary inside which a term keeps one meaning. Outside that boundary the same term means something else. That is the definition of the boundary and not a defect of the practice.

The definition is also the reason the bounded context owns the glossary. A glossary claims that each of its words means one thing. Only inside a bounded context is that claim true. Any area larger than a bounded context breaks the claim. Any area smaller than one splits a vocabulary that already agrees with itself.

What a global data model costs

One glossary for a whole system forces one meaning onto a word that two contexts use differently. Sales calls the claim it sends to a customer an Invoice. Billing calls the posted document by the same word. A single definition of Invoice serves one of the two contexts and misleads the other.

The loss is not a matter of wording. The boundary is the thing Domain-Driven Design exists to draw, and a merged vocabulary erases it. After the merge nobody sees that two teams meant two different things, because the file no longer records the difference.

A mapping instead of a shared concept

A second option keeps two glossaries and lets both reference one shared concept for a word they have in common. The project rejected that option as well. A shared definition makes one context the authority over the other. The context that did not write the definition then lives under a meaning it did not choose.

The atlas records the relation between two terms as a mapping instead. A mapping belongs to neither of the two glossaries it joins, so neither context gains authority over the other. The translation between the two contexts becomes a separate record that a reviewer can read and dispute.

The same word in two glossaries

Sales carries a concept named Customer. Billing carries a concept named Account for a party in a related role. Both entries are correct, and no third entry reconciles them.

A word that reads the same in two glossaries is a duplicate only on the surface. It is two concepts, and the format writes it twice on purpose. A maintainer who changes what Sales means by Invoice changes nothing in Billing, because the two definitions were never one.

The reasoning that keeps a rejected word inside an entry rests on the same boundary, and When a translation does harm sets it out.