Hierarchical System style in a domain-driven design

Traditional three-tier architecture

The simplest layering method is "presentation layer, business logic layer, and data access layer", which can be used to express this idea:

Pay attention to the "infrastructure layer" of the dotted line in the figure. In terms of practice, this part may be some help classes, such as sqlhelper or some tool classes, for example, textutility. These things can be accessed by other layers. Based on the concept of hierarchy, the presentation layer can only deal with the business logic layer, while the business logic layer's operations on data persistence depend on the data access layer. The presentation layer knows nothing about the content of the data access layer.

From the field-driven perspective, this layered approach has some drawbacks. First, the role of the "infrastructure layer" that provides services at all levels is messy. It can be a pure technical framework or contain or process certain business logic. In this way, there will be dependency between the business logic layer and the "infrastructure layer". Secondly, this structure highlights the "Data Access" status excessively, putting "Data Access" and "business logic" in the same position, it is no wonder that many software engineers once asked: "How should I design my data tables?"

Hierarchy of domain-driven design

The software system is divided into four layers: infrastructure layer, domain layer, application layer and performance layer. Compared with the preceding three layers, the data access layer is no longer available and is moved to the infrastructure layer.

• Infrastructure layer: This layer provides technical framework support for other layers. Note that this part does not involve any business knowledge. The well-known data access content is also placed in this layer, because data read/write is business-independent.
• Domain Layer: includes the domain objects (entities, value objects), domain services, and their relationships. The specific form of this part of content is the domain model ). The field-driven design advocates the rich domain model, that is, the business logic should be attributed to the domain object as much as possible. What cannot be attributed is defined in the form of domain services. Related domain objects and domain services,
• Application Layer: This layer does not contain any domain logic, but it coordinates tasks and maintains applications.ProgramTherefore, it pays more attention to the flow of things. In the practice of drive design in some fields, it will also be called the "workflow layer ". The application layer is the most controversial level driven by the field, and many people may be confused about its responsibilities. For example, some foreign developers may feel that since domain logic is not included, how can they coordinate their work tasks?
• Performance layer: This is easy to understand. It is similar to the performance Layer in Layer 3, but please note that although "Web Service" is a service, but it is something of the presentation layer (extjs framework + Asp.net MVC Framework)

We can also see that the presentation layer interacts with the application layer through the data transmission object (DTO), and the data transmission object is a non-behavior poco object, it aims to encapsulate data of domain objects and transfer data between layers. Why cannot I directly use domain objects for data transmission? Because domain objects focus more on domains, while DTO focuses more on data. In addition, due to the characteristics of the "rich domain model", this will directly expose the behavior of domain objects to the presentation layer.

System Structure

Because it is a domain-driven design, the system hierarchy in this case is slightly different from the traditional hierarchy. There are four layers: presentation layer, application service layer, domain layer, and basic layer. The presentation layer adopts ASP. net MVC Framework implementation; application service layer is a WCF Service; domain layer uses Entity Framework combined with domain interfaces; the infrastructure layer provides specific implementation for the entire application, such as IOC, caching, specifications, and repository. The entire system architecture can be described as follows:

 

It must be noted that there is a bidirectional dependency between the domain model and edmrepository in. In fact, the domain model only depends on the repository interface, while edmrepository is a warehousing Implementation Method Based on the Entity Framework. It implements the irepository interface and also relies on the domain model, to obtain access to the aggregation root. The key step is that the enterpriselibrary library uses dependency injection to inject edmrepository into the domain model. Therefore, the domain model does not depend on the specific implementation method of warehousing, ensuring the purity of the domain model layer.

The implementation of warehousing can be expressed as follows:

As you can see in this article,Dependency injection is a provisioner that maintains the purity of the domain model. Another provisioner is a domain event., I willArticle. The third question at the beginning of this article, namely the scalability of warehousing implementation, will be discussed in the next article, including the implementation of transaction processing and scalable warehousing frameworks.

In object-oriented programs, user interfaces (UIS), databases, and other supportCodeAnd is often directly written to business objects. Embed additional business logic in the UI and database scripts. This is because the layer is short-term and is the easiest way to run the system.

It is difficult to read and understand the Code related to the domain and a large amount of other code. A simple change to the UI will change the business logic. Changing business rules may require careful tracking of UI code, database code, or other program elements. It is impractical to implement a consistent model-driven object, and automated testing is also difficult to use. if all technologies and logic are included in every action of a program, it must be simple, otherwise it will be hard to understand.

User Interface Layer	Displays information to users and parses USER commands. External executors may sometimes be other computer systems, not necessarily human
Application Layer	Define the work that can be done by software and instruct domain objects with rich meanings to solve the problem. The tasks attached to this layer have a profound impact on the business, and it is necessary to interact with the application layer of other systems. This layer must be concise. It does not include processing business rules or knowledge. It only coordinates tasks and commissions for the domain objects in the next layer. This level does not reflect the status of the business situation, but the status of the task progress of the user or program.
Domain Layer	Represents business concepts, information about business conditions, and business rules. Although the technical details for saving the content are completed by the infrastructure architecture LAN. The state of the business is controlled and used in this layer. This layer is the core of Business Software
Infrastructure Layer	It provides general technical capabilities for the previous book, application message sending, domain persistence, and drawing windows for users to join. Provides an architecture framework. The basic architecture layer also supports interaction between the four layers.

Hierarchy in a complex program. Designed for each layer, each layer is cohesive and only dependent on its lower layer. The Standard Architecture mode is used to achieve loose association with the upper layer. All codes related to the domain model are concentrated at one layer, and they are separated from the codes at the user interface layer, application layer, and infrastructure layer. Domain objects can focus on expressing domain models without worrying about their own display, storage, and management of application tasks. In this way, the model is developed rich and clear enough to grasp the essential business knowledge and implement it.

Green Channel: Please follow my favorites to contact me

Traditional three-tier architecture

The simplest layering method is "presentation layer, business logic layer, and data access layer", which can be used to express this idea:

Pay attention to the "infrastructure layer" of the dotted line in the figure. In terms of practice, this part may be some help classes, such as sqlhelper or some tool classes, for example, textutility. These things can be accessed by other layers. Based on the concept of hierarchy, the presentation layer can only deal with the business logic layer, while the business logic layer's operations on data persistence depend on the data access layer. The presentation layer knows nothing about the content of the data access layer.

From the field-driven perspective, this layered approach has some drawbacks. First, the role of the "infrastructure layer" that provides services at all levels is messy. It can be a pure technical framework or contain or process certain business logic. In this way, there will be dependency between the business logic layer and the "infrastructure layer". Secondly, this structure highlights the "Data Access" status excessively, putting "Data Access" and "business logic" in the same position, it is no wonder that many software engineers once asked: "How should I design my data tables?"

Hierarchy of domain-driven design

The software system is divided into four layers: infrastructure layer, domain layer, application layer and performance layer. Compared with the preceding three layers, the data access layer is no longer available and is moved to the infrastructure layer.

• Infrastructure layer: This layer provides technical framework support for other layers. Note that this part does not involve any business knowledge. The well-known data access content is also placed in this layer, because data read/write is business-independent.
• Domain Layer: includes the domain objects (entities, value objects), domain services, and their relationships. The specific form of this part is the domain model ). The field-driven design advocates the rich domain model, that is, the business logic should be attributed to the domain object as much as possible. What cannot be attributed is defined in the form of domain services. Related domain objects and domain services,
• Application Layer: This layer does not contain any domain logic, but it coordinates tasks and maintains the state of the application. Therefore, it focuses more on flow. In the practice of drive design in some fields, it will also be called the "workflow layer ". The application layer is the most controversial level driven by the field, and many people may be confused about its responsibilities. For example, some foreign developers may feel that since domain logic is not included, how can they coordinate their work tasks?
• Performance layer: This is easy to understand. It is similar to the performance Layer in Layer 3, but please note that although "Web Service" is a service, but it is something of the presentation layer (extjs framework + Asp.net MVC Framework)

We can also see that the presentation layer interacts with the application layer through the data transmission object (DTO), and the data transmission object is a non-behavior poco object, it aims to encapsulate data of domain objects and transfer data between layers. Why cannot I directly use domain objects for data transmission? Because domain objects focus more on domains, while DTO focuses more on data. In addition, due to the characteristics of the "rich domain model", this will directly expose the behavior of domain objects to the presentation layer.

System Structure

Because it is a domain-driven design, the system hierarchy in this case is slightly different from the traditional hierarchy. There are four layers: presentation layer, application service layer, domain layer, and basic layer. The presentation layer adopts ASP. net MVC Framework implementation; application service layer is a WCF Service; domain layer uses Entity Framework combined with domain interfaces; the infrastructure layer provides specific implementation for the entire application, such as IOC, caching, specifications, and repository. The entire system architecture can be described as follows:

 

It must be noted that there is a bidirectional dependency between the domain model and edmrepository in. In fact, the domain model only depends on the repository interface, while edmrepository is a warehousing Implementation Method Based on the Entity Framework. It implements the irepository interface and also relies on the domain model, to obtain access to the aggregation root. The key step is that the enterpriselibrary library uses dependency injection to inject edmrepository into the domain model. Therefore, the domain model does not depend on the specific implementation method of warehousing, ensuring the purity of the domain model layer.

The implementation of warehousing can be expressed as follows:

As you can see in this article,Dependency injection is a provisioner that maintains the purity of the domain model. Another provisioner is a domain event., Which will be detailed in subsequent articles. The third question at the beginning of this article, namely the scalability of warehousing implementation, will be discussed in the next article, including the implementation of transaction processing and scalable warehousing frameworks.

In object-oriented programs, user interfaces (UIS), databases, and other supporting code are often written directly to business objects. Embed additional business logic in the UI and database scripts. This is because the layer is short-term and is the easiest way to run the system.

It is difficult to read and understand the Code related to the domain and a large amount of other code. A simple change to the UI will change the business logic. Changing business rules may require careful tracking of UI code, database code, or other program elements. It is impractical to implement a consistent model-driven object, and automated testing is also difficult to use. if all technologies and logic are included in every action of a program, it must be simple, otherwise it will be hard to understand.

User Interface Layer	Displays information to users and parses USER commands. External executors may sometimes be other computer systems, not necessarily human
Application Layer	Define the work that can be done by software and instruct domain objects with rich meanings to solve the problem. The tasks attached to this layer have a profound impact on the business, and it is necessary to interact with the application layer of other systems. This layer must be concise. It does not include processing business rules or knowledge. It only coordinates tasks and commissions for the domain objects in the next layer. This level does not reflect the status of the business situation, but the status of the task progress of the user or program.
Domain Layer	Represents business concepts, information about business conditions, and business rules. Although the technical details for saving the content are completed by the infrastructure architecture LAN. The state of the business is controlled and used in this layer. This layer is the core of Business Software
Infrastructure Layer	It provides general technical capabilities for the previous book, application message sending, domain persistence, and drawing windows for users to join. Provides an architecture framework. The basic architecture layer also supports interaction between the four layers.

Hierarchy in a complex program. Designed for each layer, each layer is cohesive and only dependent on its lower layer. The Standard Architecture mode is used to achieve loose association with the upper layer. All codes related to the domain model are concentrated at one layer, and they are separated from the codes at the user interface layer, application layer, and infrastructure layer. Domain objects can focus on expressing domain models without worrying about their own display, storage, and management of application tasks. In this way, the model is developed rich and clear enough to grasp the essential business knowledge and implement it.