Ubiquitous Language
Ubiquitous Language is the common language of professionals and development. Their terms appear consistently in conversations, models, tests, and code.
- One wordOne word, one word, the same everywhere.
- All placesConversation, ticket, test and code.
- Fixed assignmentThe German term corresponds to an English designator.
Context
Why this is important
When conversation, ticket, test and code use the same word, misunderstandings are noticed early on. Once the team determines how German technical terms fit English identifiers, such as order to order. The scope of a language is dealt with by the building block Bounded Context.
This building block explains common technical terms. For the scope of a language, see Bounded Context.
At a glance · One language everywhere
One term, four places
The shop team clarifies the words order, reservation, authorization and invoice. Each term receives a testable meaning in the appropriate context.
This is how you read the picture
- One word In the common state, the same word stands for each term in all four places.
- All places The four cards; marked red where a place differs, such as invoice instead of order confirmation.
- Fixed assignment On the cards test and code: order confirmation will be OrderConfirmation, reservation reservation.
Order confirmationNotification that the order has been received; not the invoice.
- Discussion: Deviates
"The bill for B--"1042 is out.
- Ticket: Applies to the termAs a customer, I will receive an order confirmation after the purchase.
- Test: Deviates
sends_invoice_after_order() - Code code: Deviates
invoiceService.sendInvoice(order)
3 of 4 Places Meaning Order confirmation, but say something else.
Glossary of the shop
| Definitions | Precise significance | Applicable in | Not meant |
|---|---|---|---|
| Order | Purchase order with stable identifier | Order | Basket |
| Reservation | Time-bound stock for positions | Inventory | Physical shipment |
| Authorisation | Provider confirms the payment framework | Payment | Amount already received |
| Invoice | Proof of claim with invoice number | Invoice | Order confirmation |
Benefits & limitations
Helps if:
- Domain discussions and code use different terms for the same process.
- The same words create conflicting expectations across business domains.
Boundaries
- A global glossary can mix context-specific meanings. Establish the language within each Bounded Context and describe the translations between them explicitly.
- Renaming has a cost. In code it is a refactoring; published APIs and database columns require considerably more work. Rename consistently inside the model and translate at published contracts. Bounded Context defines where the language applies.
In practice
- Collect ambiguous terms along the process. Use Event Storming to compare, for example, 'confirmed' in customer service and Payment. Record differing follow-up rules as concrete questions to resolve.
- Define meaning and scope. Describe the rule a term denotes and where it applies. Refer to the relevant Bounded Context when other areas use the word differently.
- German domain language, English code. Agree the mapping once, for example Bestellung to Order, and record it in the glossary. Keep code naming consistent: avoid BestellungService alongside OrderRepository.
- Embed terminology in implementation. Use the agreed names in operations, events and tests. Collaborative modelling in Domain-Driven Design keeps language and business rules aligned.
Read the detailed explanation
Domain experts and developers refine terms through concrete meanings and states. The same words appear in conversations, business criteria, tests and code, exposing ambiguity early. Domain-Driven Design embeds this collaboration; Bounded Context defines where a term has the same meaning.
Shared language belongs to a context and evolves with understanding. A glossary records definitions; daily use and collaborative clarification establish them in practice. When two business areas use a word differently, make the distinction explicit rather than imposing an artificial common meaning.
Use Event Storming to explore terminology in a shared process. Record what 'confirmed' means in customer service and Payment, and clarify these meanings with domain experts before embedding names in code and tests.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which places differ in the term order confirmation in inconsistent condition?
View the solution with justification
Conversation, test and code speak of the invoice. Only the ticket uses order confirmation.
ApplyingTransferred to a new situation
In the code, the class is called ReservationService, in the ticket it says “secure storage space”. What are you doing?
View the solution with justification
Change the ticket to the glossary term reservation. Conversation and ticket then say reservation, test and code remain with reservation.
EvaluateWeighing an alternative
The team wants to name the code completely German and rename existing API fields. How do you rate that?
View the solution with justification
Advantage: less translation in the head. Disadvantage: Mixing with English library names, and renamed API fields break clients. Recommendation: Set assignment, internally designate uniformly, change published fields only by translation.
Explore further
These building blocks continue the thoughts of this page.
References
- Martin Fowler - Ubiquitous Language (opens in new tab)Connects common technical language, model and implementation.
- Eric Evans - DDD Reference (opens in new tab)Reference of the DDD author to strategic and tactical patterns.
- arc42 · Glossary (opens in new tab)Define technical terms for a common understanding.
- EventStorming by Alberto Brandolini (opens in new tab)Official introduction to joint exploration of business flows and complex domains.