What is Domain-Driven Design (DDD) and what does it contribute to software development?
If you are in the software development sector, you may have heard the term DDD more than once. It refers to “design guided by the domain”, known in English as “Domain-Driven Design”.
This approach to software development defined by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software, in which he exposes a rich, expressive and constantly evolving model that seeks to solve domain problems in a semantic way.
The book published in 2004 compiles a series of patterns and recommendations focused on designing a domain model that helps address the complexity of applications. Although if you want to know more about the book, in the article “Book Review: Domain-Driven Design” by Matt Carroll explains in more detail the book by Eric Evans.
But do not get confused! The DDD is not a technology or a methodology, it is a technique that is structured by several practices that can help you make design decisions in order to focus and accelerate the management of complex domains during the development of digital projects.
But to explain it better, we go in parts …
What problem does it solve?
Depends on the case or project we can find that the complexity of many applications is not in the technical part but in the logic of the business or domain.
The dilemma begins when we try to solve domain problems with technology. That causes that, although the application works, there is nobody able to really understand how it does it.
It is common for the anti-pattern “Anemic Domain Model” to appear in English (Anemic Domain Model). If this happens, we will find objects that carry names taken from the domain and form a structure that, at first glance, looks like a domain model but the reality is that these objects are just a set of data without behavior, implemented by logic in service objects.
By doing DDD we avoid this and other bad practices, preventing us from ending up with a complicated application when maintaining it.
What does the Model mean?
The Model refers to the knowledge that the team has about the domain. This includes only the relevant part for the use cases that are implemented in the application.
The idea is that knowledge is refined and adapted constantly as you learn about the domain. The objective is to save energy in technical solutions and overload the developers to learn the principles of the business.
The Model is also defined as the common language used by developers and domain experts, which facilitates communication with experts and prevents misunderstandings.
Prerequisites to do DDD
Now that you know what DDD is, you need to meet some essential requirements:
The development must be iterative. This will be necessary to refine the domain model continuously as we learn more about it and move forward.
There must be a close relationship between developers and domain experts. As I said before, in-depth domain knowledge is essential, as is collaboration with development experts during the life of the project; this will avoid misunderstandings between the team members and offer the opportunity to gain a deeper knowledge of the domain.
To close this introduction to the DDD, I want to clarify that this technique was designed for the development of complex applications and is oriented to projects that use agile methodologies.
As you may know, one of the most complicated aspects of complex software projects is in the real-world domain that the software serves and not in its implementation; It is at this point that the DDD can help you have a greater vision and focus to evolve through successive iterations of the design.