A significant part of the work of developers consists of communicating with people who do not write code to understand exactly what needs to be done. After all, the lack of communication can provoke a delay, incorrect work, or even failure of the entire project.
Given that each group of experts has its own jargon, its own language, it will be more difficult to formulate a product requirement than to implement it. Therefore, if the team and developers speak the same language, it will greatly speed up and simplify the process.
Ubiquitous language is a term used by Eric Evans in domain-driven design (DDD) in the practice of creating a common language between developers, experts, and other contributors. It is a common set of terms and definitions that are used by all team members in all aspects of the design process.
Characteristics of a ubiquitous language
- A prerequisite for consistent terminology is that it must be built around a domain model.
- A common language eliminates inaccuracies and contradictions from subject matter experts.
- A ubiquitous language is not a business language imposed by experts.
- It develops over time rather than being determined entirely in a single meeting.
- Concepts that are not part of a single language are rejected.
- The most important thing is that the common terminology unites the people of the project team.
The process of creating a ubiquitous language
A ubiquitous language always develops, like any other natural language, so the process of creating a common language must be approached creatively.
In his book, Vaughn Vernon suggests using the following methods of creation:
Creating a glossary
You need to assemble a team of subject matter experts and developers and instruct them to create a document that tracks the team's language. The glossary document will contain all the terms and definitions that project participants use. This will be your ubiquitous language containing fixed word combinations.
Creation of documentation
Instead of a glossary, you can create documentation with informal diagrams and important software concepts.
Create physical and conceptual domain diagrams
The language used by the team allows you to accumulate knowledge and create a model. To build it, you can draw several key concepts in the form of classes, write down their names and show the relationships between them. It will be easy for each team member to understand what it is about.
Creating charts and labeling them to indicate names and actions is very useful when the number of elements involved is small.
First of all, all team members should be aware of the need to create a ubiquitous language. It is very important to understand that the meaning of certain terms or phrases can be very different in the subject area. There is a certain boundary where the concepts of a ubiquitous language have a very specific contextual meaning.
Problems of Lack of a ubiquitous language
When developers and experts disagree with the terminology of a ubiquitous language, several problems can arise:
Use a more accurate name
In conversations, you may find that users are talking about the same concept but using different words. It can be slang or an abbreviation. Within the framework of a ubiquitous language of your system, it is better to stop at a single name that everyone understands what it means.
Using a term that has never been used before
In business areas, there is already an established vocabulary. If you introduce the terminology of the developers, it will confuse people.
The only situation where the development team can suggest using a different term is if it is agreed upon by all team members.
The sentence "just rename something"
Let's imagine a situation where the design process is already underway. A short phrase asking to replace, for example, the name of a field in the user interface may result in having to rename it throughout the code. And this means that the developer will waste time and face risks.
Advantages and disadvantages
Among the advantages, it is worth highlighting that the time for mutual understanding between developers and customers is significantly reduced. In addition, the code focuses only on business logic that is easy to change. Last but not least, it's easy to switch to multiple technologies without having to worry about the technical aspects.
The only problem is that it takes a lot of time and several meetings to delve into the knowledge of the subject area. But the benefits derived from using a ubiquitous language will outweigh the time and effort spent on creating it.