Constructing your Ubiquitous Language

Chen Chen
Chen Chen
May 31 · 3 min read

Imagine the scenario where you go to a different country where you don’t speak its national language, then try to have a conversation with someone local about your favourite topic. Well, it will not be very easy for 2 main reasons — 1. You don’t understand each other; 2. You probably have different cultures. The easiest thing I’d imagine you could do would be to open up Google translate and pay the time cost of translation.

Image taken from

Metaphorically speaking, this scenario describes the importance of having aligned glossary for the problem space you’re working in. In DDD terms, a Ubiquitous Language.

On a more strategic level, you could consider different countries as different bounded contexts in the first scenario, 2 teams working on 2 different bounded contexts will typically not understand each other’s problem space, therefore conversing across teams about their bounded contexts will be more time consuming than within their own teams, due to the lack of knowledge of the other teams’ problem spaces.

An example Vaughn Vernon gave in his workshop I recently attended was ‘assessment’ in the domain of insurance, you can have risk assessment and claims assessment. If the team that was responsible for the risk assessment bounded context was to talk about their ‘assessment’ to the team that is responsible for claims assessment, they’d need to provide the context of what risk assessment is before the claims assessment team could understand what they mean by ‘assessment’, effectively teaching each other to speak to their own language.

This is fine for those 2 teams not to understand each other, as they probably don’t need to. If some integration is involved, some contract could always be formed to avoid/minimise ‘translation cost’. Tools such as Context Mapping help to identify such contract.

At a smaller scale, you could consider this scenario as members in the team working on the same thing but the team has not developed their Ubiquitous Language. This causes a few problems:

  • Domain experts get lost in a technical discussion, extra time is spent to
  • At coding level, software engineers may need to go an extra mile to understand the intent of variable namings. This will again cost extra time.

How to achieve this

There are tools which allow the team to form their own Ubiquitous Language. One of the exercises we did in Vaughn’s workshop was event storming (also described in his IDDD book), which involves both domain experts and software engineers. The flow is roughly as follows:

  • Given a scenario (workflow) within a problem space (context), everyone gets together, use post-its of 1 colour to write down possible events that could possibly occur during this scenario.
  • Put those events into a rough timeline
  • Using a different coloured post-its, start putting the commands that could potentially be responsible for each event and put them next to the corresponding events
  • Start writing down aggregate names that the commands could possibly be sending to and events that could be emitted from. Again using post-its of a third colour and put them next to the corresponding events and commands
  • Using yet another different coloured post-its, write down possible user roles for the commands/events
  • Iterate this process at lower level, write simple code along the way as proof of concept

To begins with, the team’s Ubiquitous Language could as simple as a set of glossary for certain scenarios, including verbs that describe the actions and nouns that describe the user role that actions comes from, or the objects that actions on. As you iterate further on into lower level, your glossary become code, where the naming for aggregates, commands and events become meaningful to the business. It’s also worth noting that forming Ubiquitous Language is not the only benefit event storming brings.

So in essence, developing Ubiquitous Language will help to omit ‘translation cost’, not only allowing more effective communication between domain experts and the engineering team, but also communication within the engineering team itself.

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

Chen Chen

Written by

Chen Chen

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.