Summary of. NET logical hierarchical architecture

1. Basic knowledge preparation:

1. The principle of layer:

(1) Each layer is called by the upper layer in the form of interface.
(2) The upper layer can only call the lower layer.
(3) Dependency can be divided into loose interaction and strict interaction.

2. Business logic classification:

(1) Applied logic.
(2) Domain logic.

3. Layers used:

(1) Presentation layer (user interface layer): Domain independent.
(2) Service layer (application layer): application logic.
(3) Business logic layer (domain layer): domain logic.
(4) Shared layer: Provides common code.
(5) Implementation layer: Provide interface implementation.

4. Agreement:

(1) The domain layer adopts the domain model by default
(2) The data access layer needs to reference the domain model by default

2. Hierarchical architecture

The three basic layers of hierarchical architecture are: presentation layer, business logic layer and data access layer. If the business logic layer is divided into service layer and domain layer according to the classification of business logic, the three layers are expanded into four layers: presentation layer, service layer, domain layer and data access layer. Data Access Layer 1 generally has to understand the domain model, which creates two-way dependencies between the tiers. Generally, we have the following two solutions:

1. Place the domain model in the shared layer:

Evaluation: PetShop adopts this model, but there are many shortcomings: the business logic layer is not worthy of the name, the domain model is actually a data model, which keeps the inter-layer dependency, introduces more dependencies, obviously data-driven ideas, and does not focus on the domain.

2. Define the data provider at the business logic layer:

Evaluation: NopCommerce adopts this model. Even though the service layer is separated and the resource library naming method is adopted, NopCommerce is not an DDD hierarchical architecture, but an ordinary three-tier architecture adopting the principle of domain model and interface separation. Disadvantages: Apart from the data property, there is no separation of other specific technical dependencies from the business logic layer.

3. DDD layering:

DDD layer clearly divides the business logic layer into application layer (service layer) and domain layer. At the same time, the specific technical implementation of data access and other interfaces is unified to the infrastructure layer.

1. Original DDD layering:

Evaluation: The advantage is that the specific technology implementation is separated from the domain, and the reuse value of the infrastructure layer increases. The disadvantage is that the infrastructure layer is not subdivided using the concepts of sharing and implementation. This leads to reverse dependencies in the implementation of warehousing in the infrastructure layer. Although there is no impact in the single-project solution (only formal dependencies at the namespace level), in the. NET multi-project solution, the warehousing implementation can only be separated into a way similar to the data access layer through interface separation.

2. Improved DDD layering:

Evaluation: The infrastructure layer has the characteristics of sharing layer and implementation layer at the same time. The advantage is that the formal domain is the core and the embarrassment that the domain model cannot be referenced in the implementation of warehousing in the infrastructure layer is solved at the same time. The disadvantage is that there is no distinction between the concepts of sharing and implementation.

3. The latest DDD layering:

Evaluation: The advantage is that this is really domain-centered, and there is no need to adapt again in the service layer because the infrastructure layer cannot reference the domain layer. Use the principle of dependency inversion to completely invert the dependency of each layer on specific technology. The drawback, dependency inversion is overused, again no problem in a single-project solution, but in a. NET multi-project solution it can lead to a bi-directional dependency in namespace form. As the implementation layer, the infrastructure layer basically has no reuse value. A better way is to switch the positions of the user interface layer and the infrastructure layer in the diagram.

You can consider adding appropriate sharing layers in the above figure as needed.

4. Trends in architecture:

(1) Take business logic as the core and pay more attention to business logic.
(2) Divide the specific dependencies of the business logic layer into one level and manage them uniformly.
(3) Pay more attention to reducing dependencies within solutions rather than code reuse between solutions.
(4) The separation of sharing layer and implementation layer will be more and more reflected. For example, onion architecture.

The above is the whole content of this article, and I hope everyone can like it.