During the development right communication process is one of the important parts. Lack of communication can lead to delay, wrong work, or, even, fail of the whole project. On the other hand, if business and developers speaking in the same language it can make the process much faster and easier.
During the development of a software project, all participants must be “on the same page” in terms of the meanings of the project. When somebody says the word, there shouldn’t be any ambiguity in understanding what this word means. For example, “Trade” and “Bill”. Bill can be used as one of the forms of trade representation and domain experts can use both words. But it’s not always equal words.
Do business and developers speak the same language?
Obviously not. The business has its own language, IT has its own. Sometimes, the same word can have completely different meanings. Moreover, even different business departments or different development teams use different languages.
Possible difficulties.
In case that domain experts and developers talking in different languages can easily lead to the wrong application behavior, or, even worse, wrong application architecture, which is not correctly reflected business processes. All of it usually leads to a bigger development time, bugs, and costly rewriting of functionality.
The solution: ubiquitous language.
The term “ubiquitous language” was provided by Eric Evans, author of the book “Domain-Driven Design”. This term means a common language between domain experts and developers.
Why ubiquitous language is important?
What do you imagine when hearing the word ”apple”? You can imagine apple itself, or the latest Apple MacBook model. Even if it’s just apple, what color, size, and sort? It’s important to share such knowledge between all members to avoid assumption and ambiguity. Avoiding “lost in translations” situations between domain experts and developers reducing the time of development and decreasing the risk of assumption.
How to create ubiquitous language?
There are a few ways to create it:
- Create a glossary of key terms with simple definitions. Discuss strict meanings with businesses and developers.
- Store some kind of documentation, preferably with drawings and diagrams.
- Draw a diagram or schema with project parts and actions and put names on each part and action.
And sooner or later you will create your unique language for this project and these people involved in it. Rather sooner than later.
Is the Ubiquitous language equals to business language?
No, as far as it’s not technical language. Ubiquitous language is a blend of using jargon, which creates a unique language for each particular group and project. Everybody in the project should understand the terms from this language in the same meaning without any assumption or ambiguity.
Is it established once and forever?
Obviously not. During the project evolution, new words will be added. The meaning of some words can change. When developers will gain more domain knowledge, and businesses will have more technical understanding ubiquitous language will evolve.
Developers should learn domain knowledge to understand domain experts better. Recently, in my company, there were courses about the core business details for developers. It is very useful and allows developers to understand the basics of business language.
Conclusion
It’s not easy to create such language in the project. It will demand time and patience. But benefits will outweigh the time and effort spent on creating such language.
It’s important not only to know the words of the ubiquitous language and use them in discussions among project participants with different roles. It’s also important to use this language in development. In documentation and code. use it in class naming, use it in the method, and variable names. It will help to understand it even after time and even if somebody else, who knows the ubiquitous language, will take a look at it.
Thanks for reading!
Via medium
