At a company with 40 engineering teams and dozens of bounded contexts, someone proposes a single company-wide 'business glossary' wiki to keep terminology consistent everywhere. What are the risks of trying to enforce one shared domain language across an entire large organization, and what's a better alternative?

## Why a company-wide glossary backfires The proposal to build one company-wide glossary is a natural instinct at scale — leadership sees 40 teams each inventing their own terms and reasonably worries about confusion, duplicated effort, and miscommunication in cross-team meetings. The mechanism by which this backfires is structural: ubiquitous language is explicitly scoped, in Domain-Driven Design, to a **bounded context** — a boundary within which one team's model can stay internally consistent without contradiction. A large organization is not one bounded context; it's a federation of many, each belonging to a different subdomain (billing, fulfillment, risk, catalog, support) with genuinely different concerns and, often, genuinely different correct meanings for the same English word. Trying to collapse 40 contexts' worth of vocabulary into a single glossary runs into an unavoidable tension: - **either** the glossary picks one team's definition and every other team's usage becomes 'wrong' by fiat, - **or** the glossary settles on a lowest-common-denominator meaning vague enough that no team objects — at which point the term is too generic to actually guide any one team's design decisions, defeating the purpose of having a precise domain vocabulary in the first place. ## The governance and change-rate mismatch The deeper reason this exists as a systemic risk is a governance and change-rate mismatch. A central glossary needs an owner and an approval process to stay authoritative, but the actual insight that drives language evolution — a support team discovering a new distinction like 'Chargeback Hold', a risk team refining what 'high-risk merchant' means — happens locally, in conversations between one team's engineers and that team's domain experts, dozens of times a week across the organization. A central body cannot realistically review and ratify that volume of local refinement without becoming a bottleneck; teams either wait on approval (slowing delivery) or route around the glossary entirely (making it stale and untrusted within months), and a stale, untrusted glossary is worse than none, since people stop checking it while still assuming others are using it correctly. ## The trade-off leadership is making The trade-off leadership is implicitly making by pushing for one shared vocabulary is **uniformity versus local precision and velocity**. A single glossary looks appealing because it promises to prevent embarrassing cross-team miscommunication and makes onboarding feel simpler on paper (one document to read). The real cost is that it either sacrifices the precision each team actually needs internally, or it becomes a coordination tax that slows down the exact kind of continuous, conversational language refinement that makes ubiquitous language valuable within a single context in the first place. Organizations that push hardest for company-wide terminology consistency often end up with the worst of both outcomes: a glossary nobody trusts, plus teams that never developed sharp internal vocabulary because they were busy trying to fit a shared mold. ## Failure modes at this scale Failure modes at this scale are recognizable. 1. **The most visible is glossary rot**: a wiki page gets created with enthusiasm, filled in for a few months, and then silently diverges from reality as teams evolve their actual usage without updating the central document, until new hires who trust it get actively misled. 2. **A second is 'term hijacking'**, where a politically influential team's definition of a shared-sounding word (like 'Account' or 'Customer') becomes the de facto company standard by virtue of being written down first, even though it's wrong for several other teams' actual domains, and those teams either quietly ignore the glossary or waste time arguing about it in meetings meant for something else. 3. **A third, more expensive failure mode is silent data coupling**: teams that believe they share a vocabulary sometimes skip building real translation logic between their systems, assuming shared naming means shared meaning, and then suffer the same untranslated-integration bugs as two contexts sharing a database table without an anti-corruption layer. ## The federated alternative The better alternative, well established in DDD practice, is a **federated approach**: invest in strategic design at the level of the context map rather than a flat glossary. Each bounded context keeps its own living, precise vocabulary maintained by the team that owns it and the domain experts closest to it — this is where local ubiquitous language actually lives and stays healthy. At the organizational level, the artifact that matters isn't a glossary of every term but a **context map**: a lighter-weight, deliberately maintained document naming each bounded context, its owning team, and — crucially — the relationship and translation strategy at each place two contexts genuinely need to exchange information: - customer-supplier, - conformist, - anti-corruption layer, - shared kernel. Central effort goes into keeping that map current and into a small, genuinely shared kernel of concepts where the cost of divergence would be very high (like a canonical customer or order identifier used for cross-context correlation), rather than into policing every team's internal terminology. A real-world analog is how large e-commerce or fintech organizations structured around team-autonomy models explicitly let squad-level teams own their own domain language and APIs, while investing centrally in API contracts and a small set of shared platform concepts at the integration seams — accepting local vocabulary divergence as a feature of team autonomy rather than a defect to be centrally corrected.