This content originally appeared on Level Up Coding - Medium and was authored by Yurko
Ubiquitous Language is modeled within a Limited context, where the terms and concepts of the business domain are identified, and there should be no ambiguity.
For easier understanding (at least for me I will quite often use “common language” instead, I found it’s easier to understand for non-native speakers. At least it was easier to me :) ).
Why do we need a common language?
Sometimes in our line of work, it’s harder to phrase a product requirement than to actually implement it. Different fields are complex in their own ways. In transportation, you’ll run into the concept of overbooking, in sales with “special offers,” and in trading with “stop-loss trailing orders.”
Just imagine Harry Potter, Hermione and Ron not speaking the same language when fighting Voldemort, I doubt they would have succeeded.
A ubiquitous language is a basic concept in tackling complexity. If a subject area already requires study, let’s not make things even more complicated by forcing people to understand your subject area model as well. Let’s call things the same way in the specification as well as in the code.
A simple example shows two ways of doing the same thing (giving the possibility to the sorting hat to sort out students in Hogwarts school) and while one is quite clear to everyone reading what the purpose is the other is not so.
Regardless of how software is designed, it will need to reflect clear common language within a bounded context. But two different bounded contexts can have completely different ubiquitous language, as long as the team working within the context agrees to it. That’s the same as one football team can have different names for different strategies as long as everyone within the team understands it and uses the agreed terms.
How to develop a Ubiquitous Language?
The main question how do we agree on the whole language for a specific set of people. As even within the developers are different names for the same things. There is a number of things that the whole team: developers, business, PMs, etc should do to come to achieve it:
- Draw — Express your design on a whiteboard, which can be digital. As long as everyone understands it.
- Create a glossary — Write down all the terms and definitions.
- Event storming — Domain experts and developers can achieve a fast cycle of business process learning using event storming.
- Review and update — As with everything around. The language and model will not be forever, and it’s important to regularly review it and update it if needed.
Common Issues in real life
- Unfortunately, the benefits of a unified language are not obtained for free. A unified language requires a meticulous analysis of requirements and consultations with domain experts. Often, so-called experts express opposing viewpoints on business processes and terms. Developing applications within the framework of a “ubiquitous language” requires a significant investment of time in creating a client’s internal knowledge base. This is undoubtedly good, but the problem is that this work is almost certainly not budgeted for the development of the application. Development following all the tenets of DDD and using a common language is costly and not a quick pleasure.
- “One language” is not actually “one” for the whole application and exists only within the context. Evans writes about this directly. Unfortunately, in the book, this fact is formed softly, more as a recommendation than a rule. I would highlight the paragraph in red CAPS and put it in a box. The attempt to create a single-domain model is doomed to fail. The same term can mean different things in different contexts. I can immediately name several examples from different domains, but they all require special explanation, so I will limit myself to a wizardry example: ”defeat the enemy” for Harry Potter and Voldemort mean completely different things and different approaches. Well, you got it…
- No one needs a full domain model. It’s probably too complex even for advanced strategists and analysts. These guys will ask to present the data in a completely different, understandable, and sectioned way. Contexts implement the “divide and conquer” principle, which helps to quickly train users and incorporate new members into the development team.
Keep coding and have one.
— — — — — — —
Part 1 of the DDD series can be found:
https://medium.com/gitconnected/a-practical-simple-introduction-to-ddd-cd4a104c8634
Ubiquitous (common) Language in DDD was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Yurko
Yurko | Sciencx (2023-02-06T01:53:53+00:00) Ubiquitous (common) Language in DDD. Retrieved from https://www.scien.cx/2023/02/06/ubiquitous-common-language-in-ddd/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.