Skip to content
Software Architecture Guide

Ubiquitous Language

Explanation

Section titled “Explanation”

A ubiquitous language is a common set of terms for talking about a business domain. The model acts as this language. It helps developers and domain experts communicate (see Domain Model).

It grows with understanding. The team learns more about the domain over time. The language and the model should change with that learning.

Awkward terms are warnings.

  • Domain experts should object to terms or structures that are awkward or inadequate for expressing the domain. That points to a weakness in the model.
  • Developers should watch for ambiguity or inconsistency. Both will cause trouble in the design.

Speaking it is a test. Using the language in conversations with domain experts is an important way to test it. Language and model are tied together, so the test checks the model too.

It has limits. Large organizations do not share one uniform vocabulary. Different groups use subtly different terms. Domain-driven design splits a large system into bounded contexts, each with its own unified model (see Bounded Context). A change of language marks the edge of a model. So each bounded context needs its own language.

Example

Section titled “Example”

A team builds an ordering system. In a workshop, a domain expert says, “We never delete an order. We cancel it.” The developers had named the operation deleteOrder. The term sounds wrong to the expert, so the team renames it cancelOrder and adjusts the model to match. Later, the shipping group uses “order” to mean a pick list. The team sees the different meaning and treats shipping as a separate context with its own model and terms.

Trade-offs

Section titled “Trade-offs”

The language is never finished. It must change as understanding grows, so names and models need regular revision. One term cannot cover the whole organization. Teams must accept several languages, one per bounded context, and mark where they change.

Checks

Section titled “Checks”
  • Domain terms used in the document match the terms the domain experts use.
  • The document states which bounded context each term and model belongs to.
  • Terms that differ in meaning between groups are identified rather than merged into one.
  • Ambiguous or inconsistent terms are noted and resolved.
Section titled “Related”

Sources

Section titled “Sources”