What a ubiquitous language is

Eric Evans named the practice

Eric Evans introduced the term in Domain-Driven Design in 2003. The term names a practice. Developers and domain experts build one rigorous language together. They use that language in speech, in documentation, and in the code itself.

Martin Fowler states it in one sentence

Martin Fowler wrote an entry on the term in 2006. He calls it “the practice of building up a common, rigorous language between developers and users”. The entry stands at https://martinfowler.com/bliki/UbiquitousLanguage.html.

That entry says nothing about a glossary, nothing about translation, and nothing about storage. This specification fills that gap.

One sentence of Fowler stands behind two mechanisms

Fowler gives both halves of the practice in a single sentence:

Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

The first half is the rejected word. This format keeps the objection inside the entry, with the reason against the term and the date of the decision.

The second half is the validator. This format turns the watch into a named rule set over the glossary, and a tool reports each departure by the name of the rule it broke.

The practice is the agreement, the glossary is the record

The term names a practice and not an artifact. The practice is the agreement between the people who speak the words. The glossary is the record of that agreement. This specification defines the record. It does not define the practice.

What a ubiquitous language is not

• Not a data dictionary. A data dictionary describes storage. A ubiquitous language describes what the business says.
• Not a translation table. A translation table maps one word onto another word. A glossary of this format also records the translation that the team refused, and the reason against it.
• Not company jargon. Jargon grows without agreement. A team decides a ubiquitous language, and the record keeps that decision.
• Not a single vocabulary for a whole organization. The language holds inside one bounded context. Why the language is per bounded context gives the reason.
• Not a substitute for a conversation with a domain expert. The file records what the conversation settled. It does not replace the conversation.

What the specification adds

The practice itself needs no tool. This specification adds three things to it. It gives each bounded context one file. It states a rule set that a tool validates. It records who decided each word.

The three together turn the outcome of an agreement into a document that a reviewer can read and dispute.