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.
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.
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.
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:
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 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.
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.
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.
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: