Bridging the Language Gap in Domain‑Driven Design

Hello everyone, I am Bage. This week I studied 领域驱动设计 (Domain‑Driven Design) and took extensive notes on the most insightful parts to share with you.

During regular requirement discussions, meetings often last over an hour without reaching consensus. Business side experts may express themselves clearly, yet developers fail to fully understand due to differing knowledge systems and the lack of a mutually understandable language.

Language Gap

Domain experts, while limited in technical knowledge, use their own domain terminology, often with varied styles. Developers, on the other hand, employ descriptive, functional terms that do not convey the same meaning as the experts' language.

Developers may create abstractions to support design, which domain experts cannot grasp. Different developers may produce divergent design concepts and ways of describing the domain.

Because of this linguistic gap, domain experts can only vaguely describe what they want, and developers can only form a fuzzy understanding of an unfamiliar domain.

Only a few team members master both languages, becoming bottlenecks whose translations are often inaccurate.

Mutual Translation Causes Confusion

In projects without a common language, developers must translate for domain experts, and domain experts must translate for other experts.

These translations confuse model concepts, leading to harmful code refactoring. Indirect communication hides the formation of splits—different team members use different terms without realizing it.

Because software components cannot integrate seamlessly, reliable software cannot be built. Translation work prevents the combination of knowledge and ideas that deepen understanding.

Consequences of Different Languages

If language is fragmented, projects inevitably face serious problems. Domain experts use their own terms, while the technical team adjusts language for design discussions.

The terminology used in daily talks differs from that used in code. Even the same person may speak differently from what they write, causing profound domain expressions to slip away and never be recorded in code or documentation.

Translation leads to poor communication and weakens knowledge digestion. Yet neither side's language can become the common language because they cannot satisfy all needs.

Make the Domain Model the Ubiquitous Language

The overhead and risk of misunderstanding are too high. Projects need a common language that is far more robust than the least common denominator of existing vocabularies. Through consistent team effort, the domain model can become the core of this common language, tightly linking team communication with software implementation.

Least common denominator: the smallest common multiple of two denominators, e.g., the LCM of 2 and 3 is 6, so the least common denominator is 6.

Vocabulary of the Common Language

The common language includes classes and primary operation names. Some terms discuss explicit rules in the model, while others stem from higher‑level organizational principles such as bounded contexts and context maps.

Model‑Based Language

Developers should use a model‑based language to describe artifacts, tasks, and functions in the system. This model provides a communication bridge for both developers and domain experts, and experts should also use it to discuss requirements, plans, and features.

The more widely the language is used, the smoother the understanding.

Make the model the pillar of language. Ensure the team consistently uses this language in all internal communication and in code, diagrams, documentation, and even spoken discussions.

Domain experts should resist terms or structures that inadequately express domain understanding, while developers should watch for ambiguous or inconsistent elements that hinder design.

Conclusion

In the world of DDD, both domain experts and developers should use a language that both sides can understand when discussing business. Although the language may be obscure at first, it becomes clearer as the project evolves.

A mere common language is insufficient; oral communication alone leads to knowledge loss and hampers future development. A model must be established, with all discussions based on it, and any changes reflected back into the model.