Domain-Driven Design, what is it, and how to apply it in my organization?
What is Domain-Driven Design (DDD)?
In 2003, Eric Evan published his book entitled “Tackling Complexity in the Heart of Software” in which he launched the first concepts of DDD (Domain-Driven Design), increasing its popularity exponentially ever since.
Many teams, companies, and organizations have applied this model and achieved great success in software development.
The Domain-Driven Design (DDD) is not a technology or a methodology, but a software development practice with complex needs, which places the Business Domain as the beacon of the project and in its Model, as a communication tool between business and technology.
How is Domain-Driven Design (DDD) applied?
As we know, most enterprise applications with significant business and technical complexity are defined from multiple levels. These levels are a logical element and are not related to the implementation of the service, but rather serve to help developers manage the complexity of the code.
Let’s take an example:
Take for example an entity that can be loaded from the database.
It may be that some of that information is sent from the database to the client UI via a REST web API.
The point here is that the domain entity must be placed within the domain model level and cannot be propagated to other areas where it does not belong, such as the presentation level.
Also, entities cannot be bound to client views, because some data might not be validated at the UI level.
ViewModel
But that is the purpose of the ViewModel, a data model exclusively for the needs of the presentation layer. But domain entities do not directly belong to the ViewModel. So we need to translate between ViewModels and domain entities, and vice versa.
What levels does Domain-Driven Design have?
Let’s see below a layered design of the DDD microservice:
In the image above, we can see a three-tier design of the DDD Ordering microservice.
Each layer is a VS project:
- The application layer is Ordering.API
- Domain level is Ordering.Domain
- Infrastructure level is Ordering.Infrastructure
It is very important for its proper functioning that each level communicates only with certain other levels. Also, this development approach can be easier to implement if the levels are implemented as separate class libraries, as it allows us to clearly identify which dependencies are established between the different libraries.
The 3 levels of Domain-Driven Design (DDD)
Domain model
The domain model level is the level responsible for representing business concepts, information about the business situation, and business rules.
The state that reflects the business situation is controlled and used here, but the technical details of its storage are delegated to the infrastructure.
We can say that this level is the core of business software.
Application
The application layer defines the jobs and tasks that the software is supposed to do and directs expressive domain objects to solve problems.
Tasks that are the responsibility of this layer are significant to the business or necessary for interaction with the application layers of other systems, so this layer should be kept narrow.
This level does not contain business rules or knowledge, but only coordinates tasks and delegates work to domain object collaborations at the next level.
Also, it does not have a state that reflects the business situation, but it can have a state that reflects the progress of a task for the user or the program.
Infrastructure
The infrastructure layer is how data that is initially held in domain entities, in memory, is held in databases or other permanent storage.
An example would be using code from the Entity Framework Core to implement the Repository Pattern classes that use DBContext to persist data in a relational database.
Next, you can see the ideal dependencies that each layer should have in a Domain-Driven Design service:
As we can see from the schematic above, the application layer depends on the domain and the infrastructure, and the infrastructure depends on the domain, but the domain does not depend on any layer.
Advantages and disadvantages of the model?
As in all models, the Domain-Driven Design has benefits in its favor and some disadvantages against it. But as we always say, depending on your needs or those of your client, it is necessary to analyze each case and study which model is more convenient.
Let’s see what are the advantages and disadvantages of this model:
Advantages of Domain-Driven Design
- Well-organized code, allowing testing of the different parts of the domain in isolation
- Business logic resides in one place and divided by contexts
- Long-term maintainability
- Effective communication between domain experts and technical experts through Ubiquitous Language
Disadvantages of Domain-Driven Design
- Domain Experience: Domain-Driven Design requires extensive domain experience. This means that the team should have at least one domain expert to help define all the processes, procedures, and terminology for that domain.
- Development costs: The team must implement a large amount of isolation and encapsulation within the domain model. This often results in longer development and life, which can be relatively costly. So we can say that it is not a suitable model for short-term projects or projects without a great domain complexity.