Reading Time: 4 minutes

In the article “what-is-strategic-design” I made an introduction about what is a Ubiquitous Language.
In this article, I will address other important points about Ubiquitous Language and show how you can develop a Ubiquitous Language.

To remember:
Ubiquitous Language is modeled within a Limited context, where the terms and concepts of the business domain are identified, and there should be no ambiguity.

Ubiquitous Language is the term that Eric Evans uses in “Domain-Driven Design – Tackling Complexity in the Heart of Software” in order to build a language shared by the team, developers, domain experts, and other participants.

Regardless of how your software is designed, it will need to reflect a clear and modeled Ubiquitous Language within a Delimited Context.

To produce a clear Ubiquitous Language you will have to understand more of the business.

Characteristics of the Ubiquitous Language

• Ubiquitous Language must be expressed in the Domain Model.
• Ubiquitous Language unites the people of the project team.
• Ubiquitous Language eliminates inaccuracies and contradictions from domain experts.
• Ubiquitous Language is not a business language imposed by domain experts.
• Ubiquitous Language is not a language used in industries.
• Ubiquitous Language evolves over time, it is not defined entirely in a single meeting.
• Concepts that are not part of the Ubiquitous Language should be rejected.

Common Problems

I would like to reinforce Eric Evans‘s ideas on what we should avoid:

• The lack of a common language, generating “translations”, which is bad for the Domain Model, and causes the creation of wrong Domain Models.
• Team members using terms differently without realizing it, for lack of a common language.
• Communication without using Ubiquitous Language, even if it exists.
• Creation of abstraction by the technical team for the construction of the Domain Model, which is not understood by domain experts.
• Technical team disregarding the participation of domain experts in the Domain Model, considering it too abstract for domain experts. But it is necessary that domain experts participate, because who can validate the Domain Model that was built?

How to develop a Ubiquitous Language?

You may be asking yourself: But how to develop a Ubiquitous Language? What are the methods? Who are involved? What are the processes?

The first point is that even domain experts may disagree with each other, and only with open discussions, analysis of existing documents, dictionaries, standards, and others, can we come up with a better language.

Draw

Express your Domain on a whiteboard, do not worry if they are formal
designs or not.

Create a glossary

Develop a glossary of all terms with definitions.

Use Event storming

Domain experts and developers can achieve a fast cycle of business process learning using Event Storming, which facilitates the development of Ubiquitous Language.

Review and update

Be ready to review and update what has been generated in an agile way.

These are some first steps to developing Ubiquitous Language.

Vaughn Vernon says:

The code is the enduring expression of Ubiquitous Language, be prepared to abandon drawings, glossaries and other documentation that will be difficult to keep up to date.

Your code needs to express the Ubiquitous Language

Imagine that you are developing an e-commerce system and the product owner makes the following request:

“The system must allow change Customer’s email.”

Simple, is not it?
But how would you represent this in your code?

Here is an example of implementation:

public class People : Entity
{
    public string Name { get; set; }
    public string Email { get; set; }
    ...

    public void Update(string name, string email, ...)
    {
        if(!string.IsNullOrEmpty(name))
        {
            Name = name;
        }

        if(!string.IsNullOrEmpty(email))
        {
            Email = email;
        }

        ...
    }
}

What did you think of this code? do you think it really reflects a Ubiquitous Language?

Remember that Aggregates, Value Objects, Domain Services, Repositories, Commands, Events and so on, need to express the Ubiquitous Language.

See the example below of the code that reflects the Ubiquitous Language:

public class Client : Entity
{
    public string Name { get; private set; }
    public string Email { get; private set; }
    ...

    public void ChangeEmail(string email)
    {
        Email = email;
    }
}

Conclusion

Discuss, research, conceptualize, develop and speak the Ubiquitous Language of the Domain Model.

See you soon!