Domain driven design is about optimizing a team’s knowledge and understanding of the domain it works in. Find out what DDD is and why it is so important.
In 2003, Eric Evans published a book called “Domain Driven Design: Tackling Complexity in the Heart of Software”, and for the very first time, the term Domain Driven Design (DDD) was introduced to the public.
Since the book has been published, the term began to be named in the software industry as a key practice for building quality software.
Domain Driven Design is used to solve complex problems. However, are all problems complex? Is it mandatory in 2021 to always use DDD? Why is it so important to understand what DDD really is and know when to use it?
What is Domain Driven Design?
Domain Driven Design (DDD) is a complex topic itself.
In order to explain what it is, we should first understand what a domain really refers to, at least in a development context. In a software building context, the domain represents the target subject of a specific programming project. It represents the business space.
Under this definition, DDD can be explained as a programming practice which focuses on the domain. DDD provides a set of patterns, terms, and good practices to build software from complex domains. It helps the developers manage the complexity they face when they design a solution.
Another term we should define is domain model, which is just an abstract term. Therefore, we can now explain DDD as an approach for building the domain model correctly.
The three pillars of DDD
In order to fully understand DDD, there are three concepts or pillars, we must take into account:
- Ubiquitous Language
It defines a common set of vocabulary to express the model. DDD focuses on building a simple, business-oriented language, skipping technical names or concepts. In this way, the main goal of ubiquitous language is to avoid misunderstandings and bad assumptions, a language that is well understood by everybody.
It is purely a set of terms (verbs, nouns, expressions, etc.) shared by all parties involved in the project, such as programmers, architects, business experts, and employees in the organization we are working for, among others.
In the end, this set of terms will be easily understood by domain experts and technical people alike. It should be used in all ways of communication and interaction.
It must not be ambiguous and unclear, at least in a specific context, such as a bounded context.
- Bounded Context
A bounded context represents a subdomain with its own ubiquitous language. This means that outside the boundaries of the context, the language could be different. It is really common for each bounded context, or subdomain, to have its own ubiquitous language.
Each context has its own architecture and implementation. Every single one of them has at least three goals:
- Remove ambiguity, since each term means only one thing in this context.
- Split the model into smaller pieces to make it simpler to design the software modules.
- Make it easier to integrate with other components, such as external components or legacy code.
Sometimes, the same term has a whole different meaning when it is used by other people in another context. That issue is solved thanks to the bounded context, where each term has the same meaning in all contexts.
- Context Map
The context map is simply a diagram, which explicitly represents a map of all the context boundaries and the way they communicate with each other.
Focus on who really understands the business
A key piece of DDD is to encourage better interaction with domain experts. They are the people who live and breathe the business. A common problem is when we use our — a programmer’s — language, and not theirs.
Separation of concerns
DDD guides us to divide and conquer, to focus on a single subdomain at a time, gather as many concepts from the domain experts as possible, and hopefully realize that each domain has its own tasks, terminology, and challenges. Additionally, some of the terms in one subdomain could refer to a different thing in another subdomain. Later on, those (sub)domains effectively interact with each other.
The perks of splitting the problem into different subdomains are:
- It is more flexible — easy to modify parts of the project without side effects.
- The code is better structured and organized.
- It is easier to test.
The last lines
DDD offers a wide range of advantages over other types of approaches, which can be summarized:
- The result of using DDD, the software we build, is closer to the domain, and therefore closer to the customer.
- Better communication than other approaches among domain experts and technical experts through ubiquitous language.
- It helps developers focus on smaller pieces of the problem at a time, by splitting up smaller areas of the domain (subdomain) through bounded contexts.
On the other hand, DDD is not suitable for every project. It depends on the complexity of the problem, and it is not only technical complexity but business domain complexity, too. While the complexity is higher, DDD would be a better fit. DDD is not recommended to solve simple problems such as CRUD solutions.
Besides, DDD implies discussing and modeling the problem with the domain experts. For that reason, at least one domain expert for each bounded context should be involved in the project, requiring more time and effort by the whole team. This approach has a longer learning curve compared to others, given there are new concepts, patterns, principles, and processes to learn.
To sum up
As we see, DDD provides many technical benefits, and it should be applied to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information and in the formulation of a common understanding of the domain.
In conclusion, Domain Driven Design is a wonderful approach for certain kinds of problems, where domain experts are involved in the project, and the time invested is reasonable.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
