Ubiquitous Language in Action: Boundaries Made of Words

You already know what the Ubiquitous Language is and how to define its boundaries. Equipped with that knowledge, let’s return to the Training Center example and clarify what domains and corresponding ubiquitous languages we have.

Where were we?

After our last Big Picture Event Storming session, we ended up with a lot of information, shared understanding, and a significant amount of knowledge:

Let’s take a closer look at it and apply one by one the hints we learned last time to gain deeper insights into the business.

Look for domain experts around you

Let’s go through some events to identify our domain experts:

• Some events are related to the training program—its creation and future improvements. The person who can tell us more about building it is the trainer (education domain).
  

  

• The trainer is also a domain expert when it comes to conducting training (education domain).
  

  

• After creating the program and before conducting training, we need to sell it. Here, the Sales team can explain the nuances of this process (sales domain).
  

  

• Once the training is confirmed, it must be organized. Who would know more about that area than the logistics department? (logistics domain)
  

  

In this way, we increase our understanding and collect details that help us establish domains and the language within their boundaries. We might already have some ideas, but remember: the amount of detail within a domain can be a good indicator of whether to divide it further. We’ll leave that step for later.

Of course, these aren’t all the domain experts we can identify based on the events we placed on our virtual wall. I encourage you to find more on your own and share your observations in the comments.

⚠️ Warning: Don’t confuse participants with experts

Remember: a person involved in an event (either initiating or reacting to it) isn’t necessarily a domain expert. For example, someone searching for training for themselves (a Customer) isn’t an expert in this area—they don’t prepare our training catalog. Here, the domain experts are the trainer (who creates and conducts the training) and someone from the Sales department (who builds an offer attractive to customers).

⚠️ Warning: Use roles, not names

It’s better to name your domain experts by their roles, not their actual names. Why? Because sometimes a single person or department can be responsible for more than one domain. Using role names increases your clarity and prepares you for future organizational growth.

Same word, different meaning

Let’s look at some of the events we found so far:

We have two events referring to resources, but since they belong to different domains, their definitions differ:

• Resource (logistics domain): a trainer, classroom, or piece of equipment needed to deliver a course.

• Resource (education domain): learning materials—slides, videos, or readings shared with participants.

As you can see, one refers to a person or a place, the other to content. Until we assign them to their respective domains, they remain ambiguous. Once the domain is clear, their meaning becomes obvious.

⚠️ Warning: Verify meaning differences with experts

Always validate with domain experts whether certain words truly have different meanings. Sometimes we unintentionally “merge” words with meanings borrowed from their context:

In one case, we refer to a training agenda, and in another to a meeting agenda. There are differences between them (length, topics, purpose, etc.), but those come from the difference between training and meeting. The definition of agenda itself remains the same—a plan of things to do or discuss.

Also, note that this distinction tells us nothing about domain boundaries. Both events (Training Agenda Set and Meeting Agenda Shared) could belong to the same domain or to two different ones. The word agenda alone indicates nothing in this case.

Same word, different characteristics

Let’s look at several events related to Training:

Even though the word training appears in each event, we should validate whether it represents the same concept in all cases:

• Training Ordered: here, the training is a product to sell and buy (sales domain).

• Training Scheduled / Conducted: here, the training is an event to organize, with a beginning and an end (logistics domain).

This step is easier when domain experts have already been identified. Their perspectives help us see the same event through different lenses.

Same data, different names

This time, things get trickier. Let’s look at these examples:

Training and webinar share many similarities but also many differences. Yet, if we look at this specific events, both involve a common subset of data: what is scheduled, when, for whom, and where. Looking at these details, this seems like an Event (scheduling domain). If we later need to coordinate such events—for example, to verify trainer or sales availability—it might make sense to introduce a separate Scheduling domain.

⚠️ Warning: Don’t overcomplicate the model

Always validate with domain experts whether creating a new domain or concept is justified. Our goal is to understand the business better and make systems simpler—not add unnecessary complexity just because we can.

Same person, different name across the process

Let’s analyze the person registering for a training. The same individual is called differently at various stages:

• Customer: exploring our offer (sales domain).

• Payer: confirming their purchase (accounting domain).

• Recipient: receiving payment confirmation and training details (notification domain).

• Participant: attending the training and learning (education domain).

Same item, different name across the process

A similar pattern applies to non-human entities, like invoices:

• Invoice: generated when someone pays for a training (accounting domain).

• Attachment: when sent to the payer via email (notification domain).

• Document: when archived for legal reasons (archival domain).

No interactions and no consistency

Some events clearly don’t belong in the same domain:

• Training's Fee Paid: a payment for training (accounting domain).

• Conference Talk Given: a talk delivered at a conference (education domain).

It’s hard to find a logical link between these two. There’s simply no shared context.

⚠️ Warning: Missing knowledge may hide connections

The fact that you can’t connect two events doesn’t mean a connection doesn’t exist—it might simply be hidden due to missing knowledge. Validate this with domain experts. Either they’ll confirm there’s no link, or you’ll learn something new about the business.

Putting it all together

The level of detail often determines whether a domain should be split. After walking through all these hints, we can now decide what domains we have. Don’t worry if later you realize some are too broad and need splitting, or too narrow and should be merged. That’s normal—it reflects learning and refinement over time.

Name your domains (if you haven’t yet)

Identifying domain boundaries is one thing; naming them is another. I encourage you to name each domain as soon as you identify it using today’s heuristics. This helps continuously validate whether your boundaries make sense.

Every piece of information belongs somewhere

After applying all heuristics, many events will already be placed within clearly defined domains. Yet, some may still remain unassigned. It’s important to place every piece of information into a domain, as this validates your overall structure.

⚠️ Warning: When no domain fits

Sometimes, an event won’t fit any existing domain. In such cases:

• Option 1: place it in the closest group and adjust the domain name if needed.

• Option 2: create a new domain.

Which option to choose? It depends on how far the event diverges from others. If it’s only a subtle difference, adjust the name of the domain and add event to it. If it’s fundamentally different—create a new domain.

⚠️ Warning: When event fits multiple domains

You may encounter disagreements on which domain an event belongs to. Sometimes, this means the event should appear in both. That’s fine.

Consider our earlier example:

During our workshop, an event might be written simply as Agenda Set. When assigning it to domains, we may realize it makes sense in more than one place. Just copy it and place it in both domains.

⚠️ Warning: Duplicates may signal new domain

If you find similar group of events duplicated across domains, and they have minimal (or no) differences, this might indicate the need for a new domain. Duplication often signals underlying complexity worth isolating.

Shape of domains in the Training Center

Let’s combine everything we’ve learned and look at the domains within our Training Center:

Summary

Today, we started with the outcome of the Big Picture Event Storming session and ended with clearly defined domains and unambiguous language. Making it truly ubiquitous will take time, but we’re on the right track. We now have a better understanding of the business and can communicate more effectively.

Now, take a deep breath—it’s time to prepare for the next step.