Analytical. NET Logical Hierarchical architecture

I. Basic KNOWLEDGE Preparation:

1. The principle of the layer:

(1) Each layer is called by an interface for the upper layer.
(2) The upper layer can only invoke the lower layer.
(3) Dependence is divided into two types: loose interaction and strict interaction.

2. Business Logic Classification:

(1) Application logic.
(2) Domain logic.

3. The layer 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 generic code.
(5) Implementation layer: provides an interface implementation.

4. Convention:

(1) Domain layer Default domain model
(2) The data access layer needs to refer to the domain model by default

Two. Layered architecture

The three basic levels of a layered architecture are the presentation layer, the business logic layer, and the data access layer. If the business logic layer is decomposed into a service layer and a domain layer according to the classification of business logic, the three layer expands to four levels: the presentation layer, the service layer, the domain layer, and the data access layer. The data access layer must generally understand the domain model, which will generate two-way dependencies between tiers, and typically we have the following two solutions:

1. Place the domain model on the shared layer:

Review: PetShop This model is used, but there are many disadvantages: the business logic layer is not true, the domain model is the data model, maintains the layer dependence, introduces the more dependence, the obvious data-driven thought, does not take the domain as the core.

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

Reviews: Nopcommerce using this model, even if the service layer is separated and the resource library is named, the Nopcommerce is not a ddd layered architecture, but a common three-tier architecture with domain model and interface separation principle. Cons: Apart from the Data property, no other specific technology dependencies are separated from the business logic layer.

Three. DDD Layering:

DDD Layering clearly divides the business logic layer into the application Layer (service layer) and the domain layer. It also unifies the specific technical implementations of data access and other interfaces to the infrastructure layer.

1. Original DDD Layering:

Evaluation: The advantage is to separate the specific technology from the domain, the reuse value of the infrastructure layer increases. The disadvantage is that there is no concept of sharing and implementation to subdivide the infrastructure layer, resulting in a reverse reliance on the implementation of warehousing in the infrastructure layer, although there is no impact in a single project solution (only formal dependencies on namespace hierarchies), but in the. NET multi-project solution, the warehousing implementation can only be implemented in a way that is similar to the data Access layer through interface separation.

2. Improved DDD layering:

Evaluation: The infrastructure layer has the characteristics of both the shared layer and the implementation layer. The advantage is to finally achieve the formal domain as the core and at the same time solve the infrastructure layer in the implementation of warehousing can not refer to the domain model of embarrassment, the disadvantage is also not differentiated sharing and implementation of the concept.

3. The latest DDD layering:

Evaluation: The advantage is that this is really the domain as the core, no longer for the infrastructure layer can not reference the domain layer and re-fit in the service layer. Use the dependency inversion principle to completely invert the dependency of each layer on the specific technology. Disadvantage, the dependency inversion application is over the head, and is no problem in the single project solution, but in the. NET multi-project solution will result in the formal bidirectional dependency of the namespace. The infrastructure layer is essentially no reuse value as an implementation layer. A better way is to swap the location of the user interface layer and infrastructure layer in the diagram.

You can consider adding the appropriate shared layer as needed.

Four. Trends in architecture:

(1) Take business logic as the core and pay more attention to business logic.
(2) Dividing the specific dependencies of the business logic layer into one level of unified management.
(3) Pay more attention to reducing dependencies within the solution rather than code reuse between solutions.
(4) The separation of the shared layer and the implementation layer will be more and more manifested. For example, onion-shaped architecture.