# Ubiquitous Language

**In short:** A ubiquitous language is one shared vocabulary that developers and domain experts both use. It comes from the model and is tested in conversation. Its terms hold only inside one bounded context.

## 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

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

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

- 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.

## Related

- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md)
- [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md)
- [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md)
- [Domain Storytelling](https://arc.fuet.ch/concepts/domain-driven-design/domain-storytelling.md)
- [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md)

## Sources

- [Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — martinfowler.com, accessed 2026-11-09
- [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) — martinfowler.com, accessed 2026-11-09