Engineering

What is Domain-Driven Design?

The term Domain-Driven Design was coined by Eric Evans in his book „Domain-Driven Design - Tackling Complexity in the Heart of Software“. Since then, the term has become well known amongst software developers, but it is still hard to summarize the essence of DDD with a few words. In his conference keynote, Eric came up with four points that summarize the essential parts of DDD:

• Focus on the core complexity and opportunity in the domain
• Explore models in a collaboration of domain experts and software experts
• Write software that expresses those models explicitly
• Use a ubiquitous language inside a bounded context

These points already gave a good preview to the rest of the conference, as many talks and sessions can be categorized into these topics, therefore I’ll structure the rest of this blog post alike.

##Focus on the core complexity and opportunity in the domain

The techniques of DDD are meant to solve the complex and important problems of your business and require a lot of modelling effort of domain and software experts. In order to find the most important problems to solve, Evans’ book speaks of a distillation process that extracts this part called the core domain and separates it from the supporting subdomains (that only supports the core domain, but you still want to build a good solution for it as well) and generic subdomains where you should consider off-the-shelf components). During the conference talks, I learned about two similar concepts and how they resemble the DDD concepts

• Liz Keogh gave an introduction on the Cynefin Framework which helps to categorize domains into „Simple“, „Complicated“, „Complex“, „Chaotic“ and „Disorder“ and gives advice on how to act within these categories. The core domain can then be found in the complex area, whereas the supporting subdomains are located in the complicated and generic subdomains somewhere in the „Simple“ area.
• Paul Rayner explained the Purpose Alignment Model which separates business decisions along two axes Market Differentiation and Mission Critical) into four quadrants and gives advices for each quadrant. You can find the alignment of the DDD concepts within the photo.

Explore models in a collaboration of domain experts and software experts

The collaboration aspect of DDD was what impressed me the most during the conference: Besides the talks there were always hands-on-sessions as well as an self-organizing unconference part and „Modelling with Strangers“ sessions which took place nearly everywhere. You could always find people doing collaborative modelling and event storming and many walls were filled with post-its and drawings.

The collaboration aspect between domain experts and software experts was the foundation for two further talks:

• Alberto Brandolini gave an introduction to „event storming“ and gave practical advice on how to make this technique effective. You can find the slides online.
• Cyrille Martraire gave some great advice on how to do effective requirements engineering, for example preparing for an interview) „Be genuinely interested in the domain!” / „Find a reference documentation for the domain!”) or techniques for note taking during interviews „underline new domain words“ / „find a syntax to mark questions for later“).

Write software that expresses those models explicitly

Besides the modelling techniques, the DDD book also talks about how to express the model within the software (e.g. by using Aggregates, Entities and Value Objects) and gives brief examples in Java of a sample domain. During the keynote, Eric explained that Java was just a choice of the time the book was written and was not meant to be the only implementation for DDD (and he was not really happy with that situation, see the picture of “2003 wasn’t great”).

In fact, DDD is not bound to any programming language or programming paradigm. He was also optimistic that implementing DDD has since become easier as new tools and programming paradigms have been created since. The various NoSQL datastores often offer a better fit for saving aggregates, and techniques like CQRS and Event Sourcing are an alternative way of implementing the DDD concepts.

Eric also explained the importance in really mastering the underlying technical tools. Only then you can focus on solving the domain problems instead of having to struggle with the implementation.

Use a ubiquitous language inside a bounded context

One core demand of DDD is using a shared language that is used by domain experts and software experts alike and is also present in all documents and in the code itself. However, you will not find a company-wide applicable language as different departments of a company often use the same words with slightly different meanings. Therefore it is crucial to define the boundary of a context in which the language is valid. These boundaries also have to manifest in the software.

While the book provides an exhaustive example of models within the cargo shipping domain, there are not a lot of other examples out there as people are often unwilling to talk about their most important internal business models and it is always a long process to come up with a useful model. Two speakers made an exception to this rule and gave insights into the models that they have developed which I found very interesting:

• Alberto Brandolini used his domain of organizing conferences for his example
• Yves Reynhout talked about the domain of scheduling appointments within a hospital

My conclusion

The conference left my head filled with new ideas and things I want to read and learn more about. The most important takeaway for me was that the modelling and collaboration aspect of DDD seems to be the most important one. While the implementation part of the book is really useful, it is only a means of implementing the concepts. The talks I visited were all of a high quality (I did not mention all of them in the article) and you should really watch the videos as soon as they are published online.