Why you should read the DDD (Domain Driven Design) Red Book !
After hearing several developers say good things about DDD, I started reading the Red Book (Implementing Domain-Driven Design) several days ago. I can’t resist sharing this wonderful read with you, so I’m going to try to convince you and encourage you to start reading this very interesting book.
The objective here is to explain to you what I understood about the basic concepts of DDD, what it is used for and how it works. Far be it from me to have enough experience to be able to list the pros and cons. Just to give you a taste.
Define a common language (ubiquitous language) between developers and business experts
The principle of DDD (Domain Driven Design) is to share the same vocabulary (ubiquitous language) in all divisions of a company, and this by fully including business experts and developers: it thus addresses the famous translation problem of IT.
Indeed, in the last century, my mentors explained to me that IT was essentially about translating a need (expressed by business experts) into machine language (code). This is still the case today. IT automates processes in order to save time and quality. To automate these processes, it is necessary to be able to explain to the machine (computer), in its own language, what it must do. From an almost philosophical point of view, we can say that developers are translators because they translate a processing need expressed by a human (the business expert) into the language of the machine (see following drawing).
There have been many researches and discoveries to facilitate this translation. We can mention the countless works to improve programming languages and make them more abstract. Thanks to the new generation of languages, the developer is no longer obliged to speak the language of the machine (the assembler), he has his own level of abstraction, with his own semantics (variable, function, object, etc.). Another innovation is agile methods, which allow business experts to get closer to developers and thus minimize the risks of misunderstanding. In short, if we take a step back, we can say that the objective of this work is to minimize the gap that exists between the business expert and the developer.
However, the problem remains, at some point, it is necessary to translate… and here, the DDD proposes a new approach: that the developer, in his code, uses terms that the business expert knows and uses! This does not make translation disappear, because the developer must realize the business expert’s needs (and therefore translate), but it allows the business expert and the developer to have the same language.
In fact, having a single language makes it possible to align the code with the business. This offers many advantages, such as proper knowledge of the business by the developers and therefore a greater involvement, a good understanding of the code by the business and therefore a better apprehension of its importance, a precise identification of the parts of the code which are said to be “core business”, a better agility because we know the impact of the modifications of the code on the business, a better estimation of the maintenance costs, etc.
And above all, to put an end to the amnesia of the code
The most striking advantage (for me), very well described in the Red Book, is that the DDD finally allows to end the code amnesia.
Indeed, if today the business needs are better and better translated and if they are well reflected in the source code of a software, this source code remains nevertheless very technical and its reading alone does not allow to understand the underlying business needs (even by following the principles of Clean Code… trust me).
The result is that the source code becomes amnesiac; that is to say that it no longer knows what business need it addresses. The disadvantage is that any modification of an amnesiac source code leads irreparably to cold sweats, not knowing how to measure their impact on the business…
Let’s take the following source code (from the Red Book). This code is the translation of a need expressed by a business expert, who wants to capture information about his customers. The piece of code shown allows to save a customer (saveCustomer). However, when reading this code, we have no idea what business need it embodies. Is it the initial save? The modification of a property? All of them?
This code is therefore amnesiac because we cannot link it to a business need. Changing this code becomes problematic, because we cannot measure the impact of the change on business needs. Worse, it is impossible to isolate this code to a sub-part of the business needs!
If we had followed the DDD, developers and business experts would share the same vocabulary (and there is a good chance that the business experts would have refused to use saveCustomer because it is too generic, too technical, in short not business enough).
Let’s take this other code extract (still in the Red Book). We can now see that the method name is directly linked to a business term (changeCustomerPersonalName). We understand that this piece of code is called when we want to change the name of a customer. It is a small change, but it makes all the difference.
Concepts, strategies, methods to define this common language
If you are convinced of the value of the approach, I have accomplished 90% of my goal. I just have to convince you to read… the whole Red Book.
The realization of this common vocabulary is a real challenge. There is no point in trying to hold meeting after meeting in order to reach a consensus on a common dictionary, it would be a huge failure.
And this is where the DDD comes into its own. First, it insists on defining boundaries in the definition of your common vocabulary. Indeed, if it is impossible to define a single common vocabulary for an entire society, it is much smarter to define several small common vocabularies, each focused on a particular domain. To echo this approach, the DDD proposes concepts such as “context boundary” and other “domain” and “core domain”.
Then, the DDD will explain how to build bridges between your different small vocabularies and explain the relationships that can exist between them. For example, if you are using an API that is developed by an external organization, then you are a client of the API’s vocabulary and you are even in a Consumer/Producer relationship. If this is central to your business, it would certainly be interesting to specify your vocabulary for using this API and to build a kind of overlay (anti-corruption layer).
Finally, the DDD goes much further by proposing strategies, methods and patterns allowing you to implement the approach without falling into conceptualization traps. The Red Book is a gold mine of recipes that work, but also of feedback and more than interesting examples.
To conclude
That’s it, it’s short but I hope I’ve motivated you to take a closer look at DDD. There are more than interesting ideas to apply in your projects. DDD will make you think about the architecture of your code and its alignment with your business.
There are two books to read about DDD, the Blue Book and the Red Book. I started with the Red Book, because it was delivered to me first (the blue one is waiting on my desk). Obviously, you can start with either one, but the Red Book is a bit more concrete. In any case, a more than interesting read, which I can only recommend.