Learning Domain-Driven Design (DDD) — Part 3
Domain Experts, Software Engineers, and Ubiquitous Language
Words are important. They define how we perceive the world in which we are immersed. This might be why the words word and world differ by one letter in English.
The design of digital products is no exception.
In this part of my learning journey, I want to share with you how big the role of communication and the selection of the words used in software design. I will introduce the concept of ubiquitous language.
Let’s say we are in a software company. In this context we have many actors, let’s call them the project’s stakeholders. For the sake of simplicity, I want to focus solely on two of these: the domain experts and the software engineers.
Who are the domain experts?
The domain experts are the people that know a lot about the business domain. Their bread and butter is the business, they may know nothing about software engineering, architecture, system design, or whatever.
Who are the software engineers?
Software engineers are the people that transform business requirements into code. They generally do not know much about the business domain, since it is not their main concern.
As we can see, these two profiles are very different. They are almost non-overlapping roles. They do not share common ground but are in the same business. For sure, they both want their company to be successful.
How can they cooperate?
Usually, domain experts put down some business requirements; some analysts will translate them in a more software engineer-friendly format; then, software engineers translate this document into code.
This method is broken. It is very similar to the “whisper game”. If you do not know it, the game starts with one person whispering a message to another person’s ear, who passes it further until the message reaches the final participant, who will speak it out loud. The result is very different from the original 99% of the time.
Now, imagine using this method to run a business. Software engineers will produce code that is not what the domain experts had in their minds 99% of the time. This means a 99% probability of failure. Bad, huh?!
So, how is it possible to make this process better?
Software engineers must clearly depict in their minds the business domain in order to design and build the right software. They must communicate effectively and share knowledge with domain experts.
They MUST communicate!
The solution proposed by the Domain-Driven Design (DDD) framework is to use a common language among stakeholders. This common language is called ubiquitous language. (A personal note on this name: this word is ugly, and as a non-English writer this term is very difficult to type and remember 😆)
The ubiquitous language's main goal is to break the “whispers game”. Domain experts and software engineers share a common language and by doing so they can communicate directly and they can exchange their mental models in order to produce the right software solution.
You can think of it as a bridge between the minds of two uncorrelated professionals.
In my opinion, this is huge, let’s think about the repercussions this may have on a software company:
- Software engineers know why they are doing what they are doing. They will have a clear purpose;
- Software engineers do not waste time implementing the wrong solution;
- Domain experts will see in production what they had in their minds;
- If domain experts did well their job, the right solution solved an actual problem of the customers. This means better customer satisfaction overall.
The human factor is crucial in overcoming the challenges required to reach the objectives of the ubiquitous language. It is easy to understand that is fine to declare to use a shared language, but then you have to actually define, use it and use it EVERYWHERE.
The ubiquitous language is the language of the business. So, it must be defined by the domain experts. To be clear, saying that you want to create an HTML file is not ubiquitous language. There is no room for technical jargon. Think about it when you will put your next story in JIRA in your DDD-based software company 😅
The first challenge is to use it consistently. Once you have defined the language, you have to use it every day and everywhere: in your documentation, in your JIRA tickets, in conversations, tests, source code, …
Software engineers are notoriously lazy people and they have invented a lot of tools that can keep them consistent: static code analysis, Gherkin tests, and so on.
The second challenge is to avoid ambiguity. In your language, you may have one term that has multiple meanings. Keep the term for one specific meaning and for the other ones you have to find a synonym that better fits the other meanings. You must use one term for each meaning.
The third challenge is to keep the language up to date. The business is not a static entity, it evolves continuously. The ubiquitous language is the language of the business and when the business evolves it must be updated accordingly. Domain experts and software engineers must be always “in the loop” and very close together to share the evolution of the language.
Conclusions
Communication and sharing knowledge among project stakeholders are key to creating successful software companies.
Domain-Driven Design proposes a solution to bridge the gap between domain experts and software engineers called ubiquitous language. This is a tool that, if used properly, can elevate the success rate of your next software project.
Moreover, it allows software engineers to communicate effectively with other stakeholders, which is usually an issue. We tend to use our jargon to be perceived as smart. But, in the end, we are creating walls of incommunicability between us and other professionals in our companies. This behavior may result in shipping the wrong product to the customers.
Using a shared language allows every project stakeholder to be aligned, thus shipping the right product to the customers. I think this is a topic of the uttermost importance, and I loved it to share it with you.
This is the third chapter of my journey in Learning Domain-Driven Design.
I hope you want to be an active part of this journey to mastering Domain-Driven Design. I would love to hear some feedback from you.
Do you know some videos, some courses, or some other books that I may use as a reference to truly understand this subject? I am waiting for your suggestions! 💚
These are the previous articles I have written about this topic:
