Speaking Many Languages in One System

Last time I explained what Ubiquitous Language is, why it is crucial to use it, and how it can support software evolution and maintenance. Today, I would like to share several approaches that can help you define the boundaries of domains within your application.

What Ubiquitous Language Is – A Quick Reminder

Ubiquitous Language exists only within clearly defined boundaries. Inside those boundaries, it remains consistent (terms fit together logically) and unambiguous (each word has exactly one meaning).

How We Can Identify Domain Boundaries

Every piece of software contains domain knowledge. It may not yet be documented or expressed in code, but it is present. Words, phrases, and interactions exist, waiting to be explored and understood in depth. However, this knowledge often lacks boundaries, which is why it can be misleading, ambiguous, and misinterpreted.

Fortunately, those very words and terms can help us discover and clarify domain boundaries. Several language-driven heuristics can support this exploration.

Look for the Domain Experts Around You

When building software, you collaborate with many people who help you understand what needs to be created. Some provide requirements, others support delivery. It is valuable to ask yourself whether these people come from the same area of expertise.

For example, imagine you are opening a shop. You will need to interact with many individuals. Even though the shop unites them under one business, they may live in very different “worlds,” using distinct language and specialized knowledge—for instance, an accountant, a marketer, or someone responsible for product assortment. Although the business connects them, the knowledge they possess belongs to different ubiquitous languages.

Same Word but Different Meaning

Take the word “date”. Its meaning depends on context: it could represent a calendar point in time, a romantic meeting, or even a fruit. Without clear boundaries, the word is ambiguous.

When examining your software’s domain knowledge, encountering such words is a strong indicator that they belong to different domains. Do not attempt to eliminate them by using synonyms. If the word is valid in a given context, keep it—just separate it across domain boundaries.

Same Word with Different Characteristics

The word “characteristics” can describe data, interaction, or both. Different experts may look at the same thing but from different perspectives. Consider an apartment:

1. The Architect
   Perspective: Focuses on design and structure.
   Language: Abstract and technical (e.g., floor plans, load-bearing walls, zoning).
   Difference: Describes the blueprint, not daily use.

2. The Decorator
   Perspective: Focuses on aesthetics and interior functionality.
   Language: Artistic and stylistic (e.g., color palette, focal points, furnishings).
   Difference: Concerned with visual appeal, not construction.

3. The Tenant
   Perspective: Focuses on lived experience.
   Language: Practical and personal (e.g., rent, storage space, natural light).
   Difference: Sees the apartment as a home, separate from design or decoration.

Even though they all refer to the same apartment, each perspective belongs to a different domain. Within one domain expert’s perspective, the language is cohesive, but when you move to another expert, the terms and understanding change significantly.

When exploring a business domain, you may encounter such experts. Even if you cannot identify them immediately, analyze the language: does the same phrase always mean the same thing? If not, you may be dealing with different domains.

Same Data, Different Names

Another signal of multiple domains is when the same data set is described differently depending on context. For example, consider a work activity described by: description, assignee, due date, and status. From a project management (domain) perspective, it is a Task—a unit of work in an iteration. For IT support (different domain), however, the same data is referred to as a Ticket.

Same Person Named Differently During a Process

Consider an online shop. A person browses products, makes a purchase, and receives delivery. Throughout this journey, the same person is referred to differently:

• Customer in the sales domain, when browsing and intending to purchase.

• Payer in the payment domain, when completing the order.

• Recipient in the shipping domain, when the goods are delivered.

Even though it is the same person, each step belongs to a different domain with its own terminology.

Same Item Named Differently During a Process

Similar to the previous example, but this time applied to items rather than people. In an online shop:

• Item in the shipping domain, where focus is on dimensions, weight, and handling.

• Product in the sales domain, where marketing details and attributes matter.

• SKU (Stock-Keeping Unit) in the inventory domain, where storage location and cost are key.

No Interactions and No Consistency

A hallmark of ubiquitous language is consistency: words should fit together and reinforce one another. If terms do not work together coherently, it suggests they may belong to different domains. This indicator, however, can be tricky—sometimes the missing link is simply a gap in understanding. Use it cautiously and as a last resort.

For example: castle, pen, hugging. Do you see them forming a consistent domain? Probably not.

You Need Domain Experts

The hints shared above are powerful tools to analyze language and enclose it within clear domain boundaries. Still, it is essential to include domain experts in this process. As developers or architects, our knowledge often only scratches the surface, and without expert input, we risk making poor decisions due to incomplete understanding of the domain’s complexity.

Where Can You Find Input for This Exercise?

We have already discussed Event Storming Big Picture as a technique to uncover domain knowledge and collect terminology useful for defining boundaries.

But if Event Storming is not an option (though I highly recommend it), you can use other inputs:

• Documentation

• Requirements

• Backlog tasks

• Conversations and Q&A

• … and many more

In fact, any artifact or activity that expands your business-related vocabulary is valuable. Pay special attention to nouns and verbs, as they are particularly effective for domain exploration.

Summary

Businesses often come with rich, complex, and unfamiliar vocabularies that can feel overwhelming. Ubiquitous Language is a tool to tame this complexity and make it manageable. The techniques and heuristics shared today should help you apply it more effectively and gain greater benefits from it.