The ubiquitous language is used to find an agreement between people who know the technological vocabulary and those who do not use it. Thanks to this, we can create a system so that each party understands the principle of its functioning. The language of the model should be on one level of abstraction, free of technical details.
Domain experts are involved in building the system, who do not always understand the technical jargon of software developers. Domain experts often use specialized vocabulary. This is understandable because programmers and domain experts are working on different parts of the system. Experts describe what they require and what the operation of the entire system should look like. In the next element, the software development team translates the specification into a technical language.
Without equally defined ideas, there is a situation in which domain experts must translate their vision into a language understandable to programmers and other experts. Often in the system are created slangs, wording known only to people who know the project. Developers create a domain based on their own jargon, which in turn results in the needs of the next domain translation to experts and other programmers. The project faces a problem when the language differs in the layers of the design abstraction. Each layer of the structure in the project has its own jargon, so it has to be translated every time. The terminology used in the discussion between the various levels of abstraction is completely detached from the terminology used in the source code of the system. This results in incorrect assumptions in the system and the extension of work resulting from misunderstandings and unnecessary translations.
To avoid redundant work, the project should have a common language. The concept of Domain-driven design is called Ubiquitous Language. This method contains the names of classes, functions and objects that reflect the reality as much as possible. The more the system’s domain is closer to the real shape, the understanding of the domain and making its requirements easier is easier for everyone.
One should strive to use the same formulations on diagrams, writing specifications, during discussions and in the source code. Thanks to this system domain is identical for domain experts as well as for programmers.
Example
An example of application are two talks on the functioning of the mechanism in the system for parcel shipment by transport companies.
Scenario 1: Conversation without a common language (with jargon)
User: If a person changes the mailing company, then we need to change the entire package redirection plan.
Developer: Good. We therefore need to delete all lines from the shipping table that have the user’s modified package id. We will send you a service with redirection of a new transport company to the package, which will recreate the relevant data in the table. We need to add a flag on the package, so we will know if the package has a reference to the table with the shipment.
User: Delete rows, reference, flag? Hmm … good. If the transport company which is called X is changed on the package, we would like to give it a special status.
Developer: There is no problem. We will send an inquiry checking if it is a transport company X, on which we will set an additional flag.
Scenario 2: Conversation with a language understood by both parties
User: If a person changes the mailing company, then we need to change the entire package redirection plan.
Developer: Good. We therefore need to modify all attributes in the shipment specification, then delete all the old trip plans of the package changed by the user. We will send you to the service with redirecting a new transport company to the package, where they will re-create a new travel plan.
User: If a transport company called X is changed on the package, we would like to give it a special status.
Developer: There is no problem. We will check in the shipping specification if it is a special order from the X transport company.
From the second scenario, the domain expert will understand more information than on the basis of the first conversation – this information is, among others, how the parcel shipment system works. The structure between the scenarios has changed. New objects have been defined, such as the shipping specification and the travel plan. These objects allow for a better understanding of the content by non-technical people than hidden mechanisms in the redirection service from the first scenario.
Using the intelligible language for both sides will bring much more benefits to the project and minimize misunderstandings. By modeling the system according to the second scenario, the whole model can be understood much faster than on the basis of the first conversation. In which case all specific behaviors are hidden in the redirects service and are not too clearly formulated.
