When someone asks me what Domain-driven design is for, I always tell a story that happened to me once.
I joined a new project and had long onboarding meetings where I was told what was already in place and what should be done. The language of communication was English. I am not a native English speaker, but by that time, I hadn't had any issues in communication. I was trying hard to understand the current system infrastructure, architecture, and future requirements. There was no documentation, and the only source of truth was verbal discussion. Soon, I've noticed something unclear.
First, I've discovered a tenant as a part of a multitenancy setup - a customer who owns a dedicated instance of software. Then another meaning of "tenant" emerged: a person or company who rents an apartment. Both, also, could occasionally be called users, which confused me even more. When I finally understood what was happening and pointed out that we have this ambiguous naming, the person I was speaking to told me that in his native language, they have different words for these things, but English happens to be less descriptive. As a result, we agreed to use different words and be specific to what we're talking about. It simplified my life a lot while onboarding new members on this project some time later.
And similar situations happened to me many more times. And I see that it is continuing to happen among many other teams.
Domain-driven design does not start with the code. It starts with team cooperation in discussing and agreeing to use a common project language, widely known as the ubiquitous language.
How should I start?
Follow this (not so easy as it looks) two-step plan to start with Domain-driven design:
Step 1 - Within the project team, agree on all terms you have and start using them correctly. Team members could encourage and support each other when adopting new terminology.
Step 2 - Continue using it! The project will grow and evolve, and the language must keep up with it.
If you wonder if following any DDD principles is worth your time in the era of LLM-agents writing code for you, check my article to see how you can benefit from DDD even more.
However, DDD could also benefit from adopting cutting-edge technologies. Let's see how it can help us.
The source of truth
Having a source of truth is a solid helper in any discussion. Set up a glossary with all the terminology that is domain-specific or project-specific. Start small - put the most used words and phrases. I would also recommend putting the abbreviation there if there are any, it will help a lot! It should not be fancy, it could even be a text file but shared with the whole team inside some cloud. Each team member could add new things, but editing already existing ones should require the team's approval, so everyone is aware that something has changed.
Nowadays, you can start by asking an LLM to create a first version of a glossary and propose the meaning of each term, so the team doesn't need to start from scratch. It can even group and format it nicely and prepare the format for any tool you'd like to use.
The source of truth becomes unreliable
Here comes the hardest part.
Project evolves, new functionality appears, new customers start using their own terminology, new team members bring new abbreviations, and the source of truth becomes unreliable, because it was updated 2 years ago by the person who is not even part of the team anymore.
Just as the project development process is a continuous process, the maintenance of the ubiquitous language should also be continuous. It is the only way to benefit from it, from the time you've already dedicated to its development and adoption.
And here, modern technologies could also help. You can create a recurring task to review the glossary against the codebase, tickets, documentation, and other relevant sources to see if anything new has appeared or been changed. Then, it could be a quick 5-minute discussion within the team if everyone agrees with that. It could also be done in async mode by some vote tool.
Just imagine how much easier onboarding a project would be with a documented glossary.
Came after a 2-week vacation and can't understand what the new abbreviation means? Check the glossary!
Have noticed some ambiguity in the code - check the glossary to know how it should be refactored.
Domain-driven design is not just for software developers, it is for the entire team to be able to communicate efficiently.
The article cover is Aleksandra Ekster's artwork "Venice".
Top comments (0)