UBIQUITOUS LANGUAGE: WHAT IS IT?

Author: Gediminas Geigalas

This is the first in a series of blog posts about Ubiquitous Language. It describes what Ubiquitous Language is and how it can be created.

In software development there is a common problem of using different terminology to describe the same concepts of a problem domain. Let’s take people who input data into a system as an example: domain experts might call them “employees”, analysts might narrow that term down to “system operator” and developers name them “users” in code, because some 3rd party authentication framework requires so. That might seem inevitable, however, it introduces friction in communication between team members, because mental translation between different terms is necessary. Domain Driven Design practitioners suggest to agree on a common language to be used by software development team members as well as domain experts to express the domain more effectively. This language is called Ubiquitous Language (UL).

CREATING THE UBIQUITOUS LANGUAGE

UL has nothing to do with particular technologies. It can be used regardless of the platform and frameworks that you use in your project. The primary source of terms that shape UL should not come from technology, but from business domain instead. It is not only the domain expert, however, that defines UL. Sure, most terms will definitely be taken from them, but even two experts in the same domain might use different words to describe the same thing. It is not also the role of analysts to define the UL, because they might take definitions from computer science that are and force customers to use them. Even more, the analyst might be totally new to the domain, so he might not have the experience to effectively name concepts in that domain. Same goes for developers. They might view the system as tables and columns, web services or desktop applications, but should customers understand all of that? Sure, it might be beneficial to teach them some of the technological details, so they understand, how to deal with bugs or could even take part in implementing new features (DSLs, anyone?). But if you are going to explain to the customer, that they cannot see their precious data because you accidentally used inner join instead of left join, they will not care about what you’re talking. And they don’t need to – you are the expert in SQL, not them

It is mutual understanding on the problems the system solves that we are seeking, so the efforts to create the UL need to be combined. Domain experts, analysts and developers should work hand in hand with each other to agree on common terminology used to describe the problem domain in the context of a given solution.

CONTEXT IS KING

Context is another thing to keep in mind when creating or using UL. Same terms might mean different concepts in different contexts. A customer in a CRM system is completely different from customer in a Point of Sale system. Any attempt to use UL in a different context will fail, because we are talking about different concepts then. It is common to have different UL for each subsystem, because subsystems usually deal with separate parts of the overall solution, so the contexts are different. That also has implications on source code reuse. We’ve seen many solutions that have a shared library reused across many types of applications. Time and time again we face situations where that library becomes unmaintainable simply because it does too many different things to satisfy requirements of all different context. Recognizing multiple different UL early in the development process might help fix that. It will lead to splitting your codebase into different namespaces, projects or even subsystems that serve as a boundary for a given UL. This is called a Bounded Context.

EVOLUTION OF A UL

The UL is changing as a project goes on. Even if the problem domain exists for hundreds of years, new concepts are introduced every now and then. Another reason might be the development team gaining a deeper insight into the domain. New concepts can be derived from existing ones by development team or introduced by domain experts. After everyone agrees on how to name them unambiguously, UL expands. Likewise, removing functionality from the system or moving it to other systems can make some terms redundant and they should be removed from the UL.

CONCLUSION

Ubiquitous Language can help you solve communication problems between your team members and domain experts by removing friction of using different terms to describe the same concepts of a problem domain. Ubiquitous Language is only valid in a single Bounded Context that usually represents a single subsystem in the overall solution and evolves during the project’s lifetime.

In the next post we will provide concrete examples how UL is created from customer requirements and how it is then expressed in source code.