Ubiquitous Language
Domain Driven design
What is Ubiquitous Language?
Ubiquitous language is the common language used by both the domain experts and the developers. The domain expert may not be good at technical terms and processes. He has expertise only in his domain. The developers have a good knowledge on the software development but not in different domains.
Let me give you an example in lay man’s terms. Imagine you meet a person who knows only French and you know only English. Now how will you communicate? It’s difficult right. In that situation we use sign language which is common to both. This concept is implemented even in software development.
Why do we need to use Ubiquitous Language?
Communication plays a vital role in the software development. We need to get the requirements from the domain experts before starting the development of the software. Therefore a common language used by both of them is required. If domain experts and developers speak different languages then they cannot get proper requirement which may lead to a different application
What can go wrong?
In the above image the domain expert has described his requirement in his own terminology but the business analyst understood the other way. As a result of this the end product is affected.
Alice is a manufacturer who wants to create an air traffic monitoring system. She has approached John who is a developer to develop a website. Now look at the conversation below
Alice: I want to design an air traffic monitoring system for planes.
John: Sure. Do we need to monitor the number of planes at a particular place?
Get Arthi Siva’s stories in your inbox
Join Medium for free to get updates from this writer.
Alice: Yes. And also we need to track the routes and the destinations of the planes
John: Ok then the planes can take their own route in between source and destination?
Alice: No No… the route is calculated by the latitude and altitude
In the above conversation we see that Alice who is a domain expert explains things in her own terminology. As a developer John tries to interpret things.
Example
For example, in the case of savings account and the credit cards subdomain, there is a common term called credit but it meaning differs in different domains.
Credit in savings account means adding money or depositing money. But credit card means payment against the bill (loan).
Creating a Ubiquitous language
We cannot have a standard set of ubiquitous language to use. It keeps growing as and when we add new features to the product. So continuous updation of the list of terms is important as and when a feature is added.
Use the same terminology in the code also. It will reduce a lot of confusion. If the payment gateway is called as checkout then use the term checkout in the program also to make it more readable.
Thanks for reading. Do let me know the challenges you solved by using DDD in your team in the comments.
Reference
- Eric Evans 2003 — Domain-Driven Design — Tackling Complexity in the Heart of Software
- Avram A, Marinescu F. — Domain Driven Design Quickly.pdf
#TWBloggersClub #COD #DDD

![[Done]Don’t let your automated tests go stale: Follow these best practices](https://miro.medium.com/v2/resize:fit:1358/format:webp/1*qhw1MgdkVci4Qgxc245OJg.png)






