Contents
The most important term I learned in the past months is “Ubiquitous Language”: speak the language of your domain everywhere.
The term seems to come from the world of Doman Driven Design. However, the concept behind it is broadly applicable and useful in any software development context. It basically means that we should speak the language of the problem domain we solve in our software not only with the domain experts but also among developers and even in our code.
Lost in translation
What we often see in software projects is that developers have their own terminology for the things in the problem domain, i.e. for whatever the software they build is about. Only when they talk to the business experts they switch to the actual domain terminology, and sometimes not even then.
This is bad because usually the way we speak forms the way we think. Not speaking and not thinking in terms of the problem our software is supposed to solve means we constantly have to translate from the problem language to our own language, losing information and using misaligned concepts.
Apart from the mental energy, this needs that we very well could invest in crafting a solid software, it usually leads to a solution that aligns with our own concepts and language rather than with the problem domain. Software developed that way will ever so slightly miss the actual target, and the users will have to compensate for it. They will have to translate themselves from the solution provided to the actual problem, e.g. by using workarounds or awkward workflows where the solution does not quite hit the mark.
The translation process will also give room for more serious problems, especially when we as developers start to impose our own terminology on the business experts. Using a language that does not match their mental model, it becomes hard or even impossible to see problems in our proposed solutions. Bugs will sneak in and the blaming game will start, simply because we made communication harder than it already is.
Adopt the ubiquitous language
Using the ubiquitous language (or domain language, if you will) is not hard. Developers constantly learn new terminology and concepts – at least we should be – so, learning the terms of our problem domain should be just another day in the office.
A Glossary
The easiest way to start is having a glossary of terms. It should contain a detailed explanation of each term and a distinction from other, similar terms.
The glossary should not only contain those new words we never have heard from before but also terms from the common language that may have a particular meaning in the problem domain. For example, if you are dealing with specialized kitchen appliances, the terms “cooking”, “frying” and “braising” might be way more specific than an amateur knows.
Reading the glossary usually is not enough. We need to have a feedback loop with the domain experts to determine whether our understanding of the ubiquitous language terms is right. We can do this when we talk about the requirements, but also in sprint reviews.
When we use the ubiquitous language, it is important to have only one word for a specific concept, and only one concept per word. Having multiple concepts per word leads to ambiguities, and having multiple words for a single concept leads to confusion whether there is a difference we may not have grasped yet.
The ubiquitous language in code
When we speak and think in the domain language, it is only natural to also use it in our code. It enables us to build a software that is closer to the actual problem it needs to solve, and it makes our immediately more accessible to other developers who – hopefully – also speak the ubiquitous language.
Adding terms
Often enough, developers will feel the need to add terms to the ubiquitous language. Technicalities of the software like UI elements, certain workflows or processes, may need a proper name that does not exist in the glossary and requirements yet.
In such a case, the usual reaction is to simply make up a new name. After all, naming things is what we do a gazillion times a day. But, as we know, naming is also hard. So why not get a little help? We still do not want to impose new language terms on the business experts – remember the translation problem.
So, instead of creating a new term and explanation for it, give the explanation first and then come up with an appropriate name for the concept together. That way, everybody stays in the loop and evolves the ubiquitous language as a team.
Why not call it domain language or business language?
You might ask why it’s called ubiquitous language. Well, that’s just the name that has been established for this concept.
It’s the term from the glossary. It’s the term from the ubiquitous language of software development.
Permalink
DDD and concepts such as “ubiquitous language” are indeed really important to build simple and maintainable software. A lot of things we built are only complex because they are so far away from the problem they try to solve.
You could also add that the notion is linked to a “bounded context” (a context in which the vocabulary can have a single meaning) in a future article, especially since you are referring to building a glossary. This really matters because trying to build a universal Glossary for the whole application will very likely fail.
For instance, “matching” refers to different things in “confirmation” or in “regulatory reporting” contexts of a finance application. A single glossary containing both these context might lead to confusion (and this leads to “context mappings”).
Permalink
Thanks for the input! I am aware of bounded contexts. I did not want to go “full DDD mode” in this post, so I stuck with only the ubiquitous language. I also think that this concept is useful even if you don’t do anything else that might be related to DDD. Many applications are small enough to do well with a single glossary and maybe the rare distinction of a single word meaning different things in different contexts.
Permalink
The thing is that Ubiquitous Language is only valid within a Bounded Context. Another context is defined by a different language. Context boundaries are primarily linguistic. There is a misconception that Ubiquitous Language is called ubiquitous because it is the single language for the whole business, organisation or domain. This is not the case. It is ubiquitous not horizontally, but vertically. Each context might have their own language, but all layers in this context share one Ubiquitous Language – meetings with the business, models, code, tests, UI concepts. data structures and so on.
In addition, I keep seeing the word “Glossary” each time I hit an article about Ubiquitous Language. Glossaries mainly consist of terms and in each example I see they only have nouns. This reminds me of the anaemic domain model anti-patterns, where all we have in domain objects are their properties and no behaviour. Behaviour is essential to a domain model since behaviour is what the domain does. Therefore, verbs are no less important than nouns but they are rarely found in glossaries.
The best way to capture the language is in models and in code. After a single EventStorming session, much of the language will already become visible. Most importantly, the same language needs to be used across all layers of the code and of the modelling, to make it truly ubiquitous.