Ubiquitous, But in Which Language?

A few years ago, we sat in a workshop room in Switzerland with a team that wanted to build an event-based dispatching system for their industrial operations. The stakeholders had flown in from across the country, from the German-speaking north, the French-speaking west, and the Italian-speaking south. We had everything Domain-Driven Design tells you to want, the right people in the room, real domain expertise, real business problems to solve. What we didn't have was a shared mother tongue.

Domain-Driven Design rests on the idea of a Ubiquitous Language, a precise vocabulary that every member of a project uses identically, in every conversation, every document, and every line of code. It's beautiful in theory. But it quietly assumes there is one language to be precise in. In a surprising number of real projects, there isn't. What we did in that Swiss workshop, what another client of ours did in an even more radical way, and why this matters more in Event-Sourced systems than almost anywhere else, is what this post is about.

The Comfortable Assumption

Read Eric Evans' Blue Book or Vaughn Vernon's Red Book carefully and you'll notice something interesting. Both treat language as a naming problem inside a single language. The team wrestles with whether to call something a Customer or an Account, whether Order or Purchase is the better term, whether the same word means the same thing in two parts of the business. Those are real and important questions. But they all happen inside English, with English-speaking domain experts, in monolingual organizations.

This works fine in the contexts those books grew out of. Most software is built by teams that share a single dominant language, with users who do the same. The Ubiquitous Language is something the team finds by digging into the domain, not something it has to choose between alternatives. We've covered this foundational view in DDD: Back to Basics, and for a lot of projects, it's the whole story.

But the literature is almost completely silent on what happens when the team is split across two or three native languages, or when the country itself doesn't have a single official one. The question stops being "what should we call this thing?" and becomes "in what language should we even have the conversation?" That's a different problem, and it doesn't have a textbook answer.

A Workshop in Three Languages

Back to that Swiss client. The room had Schwyzerdütsch speakers from Zurich, Romands from Lausanne, and Italian speakers from Ticino. Each of them was a domain expert, each of them had decades of experience in dispatching, and each of them spoke their own first language. There was no one in the room whose mother tongue everyone else understood. We tried German for a while, but the Romands struggled. We tried French, and the Ticinesi shrugged. We landed on English, the way most international teams do.

It worked, in the sense that meetings produced decisions. But it came at a cost that took us a while to recognize. Everyone in the room was operating in a language that wasn't their own. Subtle distinctions disappeared. When a German speaker reaches for the difference between Verfügbarkeit and Einsatzbereitschaft, the closest English equivalents are both "availability." When a French speaker explains what disposition really means in their context, English asks them to flatten it into "scheduling" or "assignment." Everyone was permanently one notch below their own expressive ceiling.

We had a dictionary on every screen and, increasingly, an LLM in every browser tab. Discussions that should have flowed turned into translation exercises. Worse, when we settled on an English term, we couldn't always be sure that everyone in the room had attached the same meaning to it. The Ubiquitous Language we ended up with wasn't really ubiquitous. It was a flattened, lowest-common-denominator dialect that nobody quite owned. The team accepted it because they had no obvious alternative. But it wasn't what the books had promised.

The Esperanto Gambit

Another client of ours took a radically different route. They had the same problem, a multilingual team where English would have advantaged the native speakers and disadvantaged everyone else. Their answer wasn't to find a language closer to a shared mother tongue. It was to deliberately pick one nobody knew.

They modeled their domain in Esperanto.

This isn't a joke. Their reasoning was that any natural language gives an unfair edge to the people who grew up speaking it. By choosing a language that practically nobody speaks fluently, they leveled the playing field. Everyone was equally a beginner. Everyone reached for the dictionary. Nobody had a head start. Fairness, achieved through shared incompetence.

We don't recommend this as a default. The friction is enormous, the talent pool of Esperanto-fluent developers is not exactly deep, and the cognitive cost of operating in an artificial language is real. But it's a fascinating thought experiment about what a Ubiquitous Language is even for. Is it primarily about precision? About communication? Or is it also about fairness, about who gets to feel at home in the conversation? The Esperanto choice answers a question most teams never bother to ask.

Some Domains Pick the Language for You

There's a second axis we haven't touched yet. So far we've talked about teams that don't share a language. But sometimes the domain itself dictates which language the model has to use, regardless of who's on the team.

Build a todo app and the language is a free choice. The domain is generic, the terms are unregulated, and you can call your aggregate Task or Aufgabe or Tâche and nobody in the world cares. But move into tax law, social insurance, healthcare regulation, or anything else with a legal anchor in a specific jurisdiction, and the situation flips. The canonical terms exist in exactly one language, defined by a regulator, and translating them strips away regulatory precision.

Umsatzsteuer isn't quite VAT. VAT isn't quite TVA. Each is the legally defined term in its own jurisdiction, with its own set of rules, exemptions, and edge cases attached. Translating between them is a lossy operation. The same is true for Sozialversicherungsausweis, for Personenstandsregister, for the Italian codice fiscale, for the British National Insurance number. These aren't names you can swap freely. They're handles to specific bodies of law.

This has direct consequences for event names, as we've argued in Naming Events Beyond CRUD. Once the domain language is fixed by regulation, your events should reflect it precisely, not paraphrase it into a more comfortable English equivalent. The more formalized and regulated the domain, the less freedom you have in choosing the language. And that's a feature, not a bug. It means the language is anchored in something durable.

When the Country Has No Single Language

Now combine those two axes and you get the hardest case. A regulated domain and a country without a single dominant official language.

Switzerland is the canonical example. Four national languages, three official at federal level, all of them equally authoritative. A Swiss federal law exists in German, French, and Italian simultaneously, and all three versions carry equal legal weight. There's no canonical source language to defer to, no "real" version that the others translate from. The same structural problem shows up in Belgium between Dutch and French, in Canada between English and French, in many parts of India, in South Africa with its eleven official languages.

In these contexts, the question "what language should the Ubiquitous Language be in?" doesn't have an answer that respects the domain. Every choice privileges some part of the country over another, and there's no neutral position. The English bridge feels neutral but isn't, because it's still a foreign language for everyone involved. Picking any one official language disadvantages the speakers of the others. Picking all of them simultaneously is the most honest option, but the most expensive.

This is the case the DDD literature simply doesn't address. It isn't a niche concern. It's the daily reality for any company doing serious business in a polyglot country, and it's becoming more common, not less, as software crosses borders.

Why Event Sourcing Raises the Stakes

In a CRUD system, the language you pick is mostly cosmetic. A class name is cheap to change. Refactor, deploy, done. Nobody outside the codebase ever sees it. If you regret calling something Order instead of Auftrag, you can fix it in an afternoon.

Event Sourcing changes that calculation completely. Events are immutable. Once you've written RechnungAusgestellt to your event store and built a decade of history on top of it, you don't get to rename it to InvoiceIssued. The historical events stay where they are, with the names they were born with. Any new code that wants to read them has to know the old name forever. The language of your events isn't a refactoring choice, it's an architectural commitment with a multi-decade lifetime.

This is why we've argued before that it was never about the database. The events are the long-lived contract, the part of the system that outlives every framework, every UI, every read model. And the language those events are written in is part of that contract. Choose carelessly and you'll be reading German event names in a French codebase ten years from now, or vice versa, with no way to tidy it up without an expensive migration.

This is also why the language question deserves more attention in Event Sourcing than it gets. In CRUD, you can be sloppy and recover. In Event Sourcing, sloppiness compounds. The decision you make today, about whether to write events in English, German, or both, is one you'll be living with for a very long time.

Bounded Context, Bounded Language

There's an answer hiding in plain sight in the DDD canon, and it's one that the community doesn't talk about often enough. A Bounded Context can have its own language. That's the whole point of the boundary.

The DDD literature tells us that different Bounded Contexts can use different vocabulary for what looks like the same concept, with explicit Anti-Corruption Layers translating between them. Most examples treat this as a vocabulary difference within a single language, but there's no reason it has to stop there. A Swiss company could legitimately run one Bounded Context for the German-speaking branch in German, another for Romandie in French, with explicit translation between them. The Anti-Corruption Layer becomes a literal translation layer, not just a structural one.

This is more honest to the multilingual reality than pretending that one language fits all. It also forces a useful discipline. If you have to translate explicitly at every context boundary, you stop pretending that two terms in two languages mean exactly the same thing. They almost never do. Acknowledging this in the architecture is better than papering over it with a translation table buried in a config file.

It's a reframing of a problem we've explored from a different angle. We've written about how great minds should not think alike, they should think together, about how even within a single language the DDD community can't agree on terminology. Multilingual fragmentation is the same problem at a larger scale. The fix is the same too. Stop pretending the fragmentation isn't there. Make it explicit. Architect around it.

There Is No Universal Answer

We've walked through the landscape. English as a pragmatic bridge, with the cost of nuance loss and a flattened common dialect. A chosen national language, easy when the team is monolingual but politically loaded when it isn't. A neutral artificial language like Esperanto, fair but expensive. Parallel languages per Bounded Context, the most honest option but also the most demanding to build. Each has costs. Each has contexts where it's the right call.

The DDD literature's silence on this isn't malicious. It's a blind spot, born from being written in mostly monolingual contexts by mostly monolingual authors. The Ubiquitous Language is still the right goal. It just isn't always available in the form the textbooks suggest. And when it isn't, you have to pick from a menu of imperfect options, knowing that whichever one you pick, you'll be paying a cost somewhere.

If you're working on a multilingual project right now, our advice is simple. Don't let the language question be answered by accident. Make it an explicit architectural decision, write down the reasoning, and accept that you're trading something either way. The teams we've seen suffer most from this aren't the ones who picked badly. They're the ones who didn't pick at all and let the language drift into whatever the loudest senior engineer happened to use.

A small postscript, since the topic invites a little fun. If we ever found ourselves in the Esperanto situation, we'd probably argue for Sindarin instead. Tolkien's Elvish is, to our ear, considerably more beautiful, and if you're going to inflict an artificial language on your team, it might as well sound nice.

If you'd like to read more about how language fragments even within a single tongue, great minds should not think alike, they should think together picks up the story from a different angle. And if you have your own multilingual modeling experiences, your own painful translations, or your own Esperanto-shaped solutions, we'd love to hear from you at hello@thenativeweb.io.