Since the domain-driven architecture was launched by the Microsoft Spain team, it has been applied in many projects, but you will also find that there are still many projects or early projects still using the three-tier architecture. Both of these architectural patterns are used in the project. Here is a summary of my own experience.
First, let's take a look at the classic three-tier architecture:
Through the architecture diagram, we can intuitively know that the goal of the three-tier architecture is to reduce the coupling between the layers, and to make the layers have better scalability through interface dependencies. The three-tier division is basically irrelevant to the business. Usually, we use the three-tier architecture in the project and we will create three-tier code based on each module.
Second, look at the domain-driven architecture:
Here are the meanings and contents of each layer (which can be found online):
Infrastructure layer : This layer actually spans all layers and includes all the infrastructure used by the system. It is generally subdivided into two sub-categories, and the content for data persistence will be listed separately. Other parts, such as the general technical framework of access, such as exception capture and processing, logging, authentication, authorization, verification, tracking, monitoring, caching, etc., are classified into another type.
Domain Model Layer : Displays business/domain logic, business processing status, and implements business rules. At the same time, the domain model layer also contains the status information of domain objects. This layer is the core part of the entire application. It can contain the following concepts and content:
Entities,
Value Objects,
Domain Services,
Repository Contracts/Interfaces,
Aggregates and their factories (Aggregates and Factories)
Aggregate Roots (Aggregate Roots)
Specifications
This layer usually defines the content of domain objects and business interfaces (core layer).
Application layer : The application layer is used to coordinate the work of the domain model and other application components to complete a specific, well-defined system task. This coordination can include: transaction scheduling, execution of UoW (Unit Of Work, PoEAA), and invoking some processing tasks necessary for the system. The application layer can also include application optimization, data forwarding, and format conversion. Of course, we collectively refer to these tasks as "task scheduling". As for the core part of each task, the application layer will forward it to the lower layer. deal with. The application layer is often seen as a "Business Facade", but it is not as simple as forwarding processing requests/feedbacks from the domain model layer. It can usually contain the following:
- The persistence layer mechanism is accessed through the Repository Contract to read or save domain objects. Note that the repository contract is accessed here, not the specific implementation of the repository. The specific implementation of warehousing is the content of the infrastructure layer
- Organize and organize data from different domain objects so that the distributed service layer can deliver it more efficiently. Usually, we organize data in data transfer objects (Data Transfer Object, PoEAA), such as WCF's Data Contracts
- Manage and maintain the state of the application (not the state of the domain objects in the domain model)
- Coordinate the collaborative relationship between domain objects, domain model and infrastructure layer components. For example, in a bank transfer system, when funds are transferred from one account to another, the "account" field object needs to be read through the warehouse first, and then the transfer operation is performed on the field object (which can be the behavior of the "account" itself, or the , according to Evans' example, using Domain Service). Perhaps after the transfer is completed, whether it is successful or not, an outgoing email needs to be sent, which requires the collaboration of the email components of the infrastructure layer to complete
- Application Services: First of all, it should be noted that the services mentioned in DDD are not the same concept as the usual Web Service. It can exist in the application layer, the domain model layer or even the infrastructure layer. The concept expressed by Service in DDD is actually a collection of a series of operations that "cannot be attributed to any one object". Therefore, Service usually coordinates the work between different objects. The same is true for application services, which coordinate other lower-level components (such as the domain model layer and the infrastructure layer)
- Business workflow (Business Workflow): Business workflow is not necessary, for some business processes composed of specific steps, the introduction of business workflow will make the problem easier
Presentation layer (Presentation) : The main responsibility of this layer is to display the necessary data information to the user through the user interface, and to receive user feedback. The components in this layer mainly implement user interface functions such as graphical interface, user operation capture, and data forwarding. It is recommended to use relevant patterns (such as MVC, MVP or MVVM, etc.) to subdivide these components into smaller layers according to the actual situation of the project.
3. Domain-driven characteristics
and three-tier architecture Different domain-driven relationships are not top-to-bottom dependencies, but leapfrog, which can be more intuitively understood from this diagram:
- Domain-driven infrastructure spans all layers
- The application layer can access both the domain layer and the persistence layer in the infrastructure
- Of course, it is more conventional that the domain layer can rely on the persistence layer
Why is this happening? With the maturity of Ioc and orm technologies and the introduction of these concepts by domain drivers, the scalability of the three-tier architecture can be solved directly through various IOC frameworks, and there is no need to emphasize three-tier isolation. This allows the layered domain-driven architecture to focus more on the business, that is, the domain.
From a business point of view, the domain layer is the core. It defines the interface of the domain objects and the core, and the process of injecting the persistence layer through Ioc can be implemented. This layer introduces many concepts, such as aggregation based on a business subject and open access to the outside through the aggregation root, which actually achieves high cohesion from the business level.
Let's talk about the business layer, this layer is the packaging of specific applications, such as wcf services, webservices, etc., usually specific business logic + calling the domain layer to complete the work; you can also directly call the persistence layer, why is this, because it is also ioc Extensibility and coupling issues are resolved.
The presentation layer is another topic, such as mvc.
The realization of the above content is actually completely dependent on the IOC and ORM technologies in the infrastructure layer. The former solves the problem of strong coupling between layers, and the latter solves the problem of persistent coupling and specific storage dependencies.
The introduction of AOP technology allows the domain architecture to solve problems from aspects and simplify the processing logic.
Therefore, in my opinion, domain-driven and three-tier are not contradictory. It is an upgraded version of the system architecture, which shifts from the architectural goal of achieving low coupling and scalability to focusing on business. It is not that it does not achieve these goals, but the mature ioc technology makes the previous goals no longer a problem, and more focus on business and fields. Therefore, domain-driven is also more suitable for business scenarios with complex technology and business, and many external services.