The term “Ubiquitous language” may be new to you. Yet Ubiquitous language is an important concept in software development .
As a software development team, What you need the most, is to communicate with domain experts as much as possible. A better communication leads to a better understanding and a better understanding leads to a better product as the result.
So we know communication is the key. But why communication does not go well? The short answer is : “Developers and domain experts have no common language”. Thus they cannot truly understand each other requirements.
Developers understand the “Language of Codes” while domain experts use the “language of processes”. So they can not understand what the other person wants.
It is where Domain driven design enters the game. As you design the domain in Domain Driven Design, You care about the processes more than classes and objects. What you do is to model the processes, not the classes nor the database.
It may be a little confusing in the beginning. Later, You get addicted to “process modeling” approach . Modeling the processes instead of classes and database, has the advantage of focusing on the requirements instead of classes.
While focusing on the requirements, You get a better chance of understanding your customer’s view.
If you are familiar with scrum and agile, You may know “User Stories” are built on this concept too. You model the process.
So in Domain Driven Design, the common language between domain experts and developers is called Ubiquitous language .
The Ubiquitous language is required for communication between the domain experts and developers.
As Martin Fowler mentions here ,
This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.
now you may understand better why aggregates lead to Ubiquitous language.