A concept model is useless if you're the only one using it. Its power comes when the business, the code, and the AI agent speak in the same words. This practice is called the ubiquitous language, and it's the most underrated idea in DDD: not about architecture, but about how to stop losing meaning in translation.

The telephone game of translations

Look at how many translations an ordinary requirement goes through. The business says "the customer abandoned the cart." The analyst writes "a session with an unplaced order." The developer names it abandoned_cart, while pending_order lives next door in the code — "it's almost the same thing." The tester verifies "an incomplete purchase." Four phrasings, each with a slightly different meaning: almost the same — and "almost" is where defects are born.

Every translation is a point of meaning loss. The ubiquitous language removes the translations: a word from a business conversation goes into the model, from the model into the code, from the code into tests and prompts — unchanged along the way. If the business says "cart abandoned," the code has CartAbandoned, not "roughly the same thing in other words."

A practical consequence: if a concept in the code has no word from the business language — that's a signal. Either you invented an entity the domain doesn't have (why?), or the business uses a concept your model lacks (what haven't you understood yet?).

Words change meaning at boundaries

The second half of the idea, without which the first doesn't work: don't try to build one vocabulary for the whole company. We've already seen it in the concept model: a "customer" for marketing, payments, and delivery is three different concepts. This isn't disorder to be defeated — it's the nature of domains.

DDD's answer is bounded contexts: the ubiquitous language holds inside a boundary. Within the payments context a "customer" is always a payer with payment details — no other meanings. At the boundary between contexts an explicit translation happens: the "order placed" event from the orders context becomes "a payer appeared" in the payments context — and that translation is written down, not performed inside someone's head.

Stretching one meaning across everyone produces that "universal" monster concept, inconvenient for all. Honest boundaries with explicit translations are cheaper.

The vocabulary is an artifact, not folklore

The ubiquitous language works only if it's written down. The minimal format is a one-page glossary:

  • Term — the exact name (and the name in code, if it differs — though better if it doesn't).
  • Definition — one or two sentences, no "well, everyone knows."
  • Boundaries — in which context it holds; how it differs from a similar term in a neighboring context.
  • States/rules — if the concept has a lifecycle.

The sign of a living vocabulary: in review you can say "we have no concept of a 'subscription,' we have a 'recurring payment'" — and that's an argument, not a matter of taste.

The vocabulary and the agent

For a product engineer the ubiquitous language has gained a third consumer — the AI agent. And it's the most demanding one: a human at least senses that "something's off here"; the agent silently completes the gaps with guesses.

The vocabulary in the agent's context (system instructions, project memory, the spec) is a contract: the agent names entities the way the business does; doesn't invent synonyms (Order, not Purchase in the second session); respects the recorded state rules. Three agent sessions without a vocabulary produce three incompatible solutions — not because the model is bad, but because each time it re-guesses your system of concepts. The vocabulary makes guessing unnecessary.

In short

  • The ubiquitous language is one vocabulary for the business, the model, the code, the tests, and the agent; a word travels the whole path unchanged. Every "translation" between jargons is a point of meaning loss.
  • No business word for a concept in the code — a signal: either a redundant entity or an ununderstood domain.
  • One company-wide vocabulary is impossible: words change meaning at context boundaries; inside a boundary — a strict meaning, at the boundary — an explicit, written translation.
  • The vocabulary is a written artifact (term, definition, boundaries, states), not an oral tradition.
  • For the agent the vocabulary is a contract that removes guessing: without it, every session reinvents your concept model.

Next — from the concept model to a spec: how the vocabulary and the model turn into the document an agent builds a feature from.