What is Ubiquitous Language?
Ubiquitous Language (UL) is something that can make or break your project. When developing a piece of software, the goal is invariably to solve some form of real-world problem. Chances are, that this will be a unique solution to a unique problem, as if it isn’t then there’s a good chance something already exists to solve that problem. Ubiquitous Language (UL) is the vocabulary used to describe the concepts and artefacts of the real-world problem that can be directly translated to the concepts and components of the software solution.
UL makes sure that all stakeholders in a software project are speaking the same language when talking about the same concepts, making communication easier and aiding in the understanding of the project. It is defined by the Domain Driven Community as:
A language structured around the domain model and used by all team members to connect all the activities of the team with the software
Why is it so important?
At Ambix, we have an agile culture and use Scrum to organise our work. We also use domain-driven design (DDD) techniques for large portions of our software. The key link between both of these is that the end user (“Product Owner” in Agile or “Domain Expert” in DDD) is heavily involved in the planning and review phases of our project work. This means that we need our development teams and our end users to clearly understand each other.
Naturally, developers will tend to use well established technical terms for things that they work with. This is great when they are communicating amongst themselves, but can cause problems when the end user is involved as they might use different language to define the same concepts. There could even be differences in language used between front-end and back-end developers. There could even be a scenario where two developers understand the same concept but use a synonym of the original word to describe it. What ends up happening is that concepts get confused or interpreted differently by different groups of stakeholders, which results in slower development or a sub-standard product.
By allowing the end user to drive the formation of the UL, your most important stakeholder can be confident that the problem domain is fully understood and therefore that the resulting solution is going to actually solve that problem. It also means that everyone in each team involved is using the same vocabulary to describe the parts of the solution that they are responsible for; an “order” in the server-side code is an “order” in the front-end and both represent a real-world “order”, for example.
Stick to it!
It can be tempting to allow the use of synonyms or even the word “thingy”, to creep into discussions, the assumption being that everyone in the discussion ‘knows what you mean’. Although it may seem pedantic at first, this should be actively discouraged by all team members as it dilutes the already well defined vocabulary and defeats the purpose of having UL.
This doesn’t mean that once defined, your UL cannot change. The UL should evolve in sync with the project and it’s underlying concepts. Changes in the real-world language used and code re-factoring alike should influence the UL so that it all stays consistent. If a concept begins to lose clarity, you can then be sure that it concept is at fault, rather than the way it’s being described.
There are plenty of resources out there to get started in UL, whether you’re looking to go down the route of DDD or not. Some good examples are included below: