Discovering Domain Knowledge

I’m continuing my way through Learning Domain-Driven Design by Vlad Khononov. Chapter 2’s argument, stripped of jargon: most software fails not because we can’t write the code, but because the domain knowledge gets distorted on its way from the people who own it to the people typing the keystrokes. The fix is mundane and extremely hard — actually share a language.

The Telephone Game

The traditional software development lifecycle treats domain knowledge as something to be progressively translated. Domain knowledge becomes an analysis model. The analysis model becomes a requirements doc. Requirements become system design. System design becomes source code. Each hop loses fidelity, and each translator is biased toward their own concerns.

Khononov calls this the children’s game Telephone, and the metaphor is right. By the time the message reaches the engineers, it’s distorted — sometimes obviously, sometimes subtly. The result is the same either way: software that solves the wrong problem, or the right problem in the wrong way. Either failure looks identical from a distance.

Ubiquitous Language as the Antidote

The proposed alternative is straightforward: stop translating. If different roles need to communicate efficiently, they should speak the same language. DDD calls this the ubiquitous language — a single shared vocabulary used by engineers, product, designers, and domain experts when describing the business domain.

The rule that makes this real, not theatre: the language is the language of the business. Business terms only. No technical jargon — no nullable fields, no event payloads, no microservice names sneaking into conversations about how the company actually works.

The piece that took me a second to absorb: the test isn’t whether engineers can use the language. It’s whether domain experts are comfortable using it. If they aren’t, what you have isn’t a ubiquitous language — it’s an internal engineering dialect that domain experts politely tolerate in meetings.

The Discipline of Precision

The language has to be precise and consistent. No synonymous terms. Each word used in its specific context. The whole point is to eliminate assumptions and make the business logic explicit.

This is where I notice a lot of codebases drift. When user, customer, account holder, and member all show up in the same module — sometimes for the same concept, sometimes for subtly different ones — that’s the tell. It’s not a naming bug. It’s evidence that the conversation that should be cultivating the language has stopped, and everyone is now improvising vocabulary on their own.

Synonym creep is one of the cheapest signals to read. It says nobody owns the words.

The Model Is Not the Territory

The ubiquitous language is the model of the business domain. Cultivating one is modeling work. And the model, importantly, is not supposed to be a faithful copy of the real world.

Khononov leans on George Box here: “All models are wrong, but some are useful.” A model is an abstraction. Abstractions handle complexity by leaving things out. The right question isn’t does this model capture everything? — it’s does this model capture enough to solve the specific problem the software exists to solve?

That reframing matters because it gives you permission to ignore detail. The job isn’t completeness. The job is usefulness.

Cultivated, Not Captured

This is the part I keep returning to.

It’s tempting to treat the ubiquitous language as a deliverable. Stand up a wiki glossary. Write a Gherkin suite. Document the terms in an ADR. Tick the box. Move on.

But the language isn’t an artifact. It’s a practice. The artifacts are snapshots — useful only as long as the conversation behind them is alive. The moment the conversation stops, the glossary starts lying. Terms shift in the business and the wiki doesn’t notice. New edge cases appear and the Gherkin doesn’t cover them. The map drifts from the territory, silently.

Glossaries are good at nouns. Gherkin is good at behavior. Neither replaces the standing conversation with a domain expert. The tools support the practice; they don’t substitute for it.

Individuals and interactions over processes and tools.

The Agile Manifesto line lands harder in this context than I remembered. The processes (the SDLC translations) and the tools (the wiki, the Gherkin suite) are exactly what people reach for when they want to avoid the interactions. DDD’s claim is that you can’t avoid them — and that the moment you try, the whole thing starts rotting.

Onward to chapter 3, where the question becomes: once you have a ubiquitous language, where do its boundaries lie?

Part of the Learning Domain-Driven Design series.