Analysis. NET Logic Layered Architecture _ practical tips

I. Basic KNOWLEDGE Preparation:

　　1. The principle of the layer:

(1) Each layer is provided with an interface for Upper call.
(2) The upper layer can only call the lower level.
(3) Dependence is divided into two kinds: loose interaction and strict interaction.

　　2. Classification of Business logic:

(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 common code.
(5) Implementation layer: Provide interface implementation.

　　4. Agreement:

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

Two. Layered architecture

The three basic layers of layered architecture are: presentation layer, business logic layer, and 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 tiers are expanded 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 produces bidirectional dependencies between tiers, and typically we have the following two solutions:

　　1. Place the domain model on the shared layer:

Evaluation: PetShop Adopt This kind of model, but many disadvantages: the business logic layer is not the same, the domain model is the data model, maintains the layer dependence, introduces more dependence, the obvious data drives the thought, does not take the domain as the core.

　　2. Define the data access interface at the business logic level:

Evaluation: Nopcommerce Use this model, even if the use of the separation of the service layer and the use of resource library naming, but Nopcommerce is not a ddd hierarchical architecture, but the domain model and the principle of the interface separation of the common three-tier architecture. Disadvantage: Apart from the data house, no other specific technology dependencies are separated from the business logic layer.

Three. DDD Layering

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

1. The original DDD hierarchy:

Evaluation: The advantage is that the specific technology is separated from the domain, and the reuse value of the infrastructure layer increases. The disadvantage is that there is no use of shared and implemented concepts to subdivide the infrastructure layer, resulting in a reverse dependency in the implementation of warehousing in the infrastructure layer, although there is no impact in a single project solution (only formal dependencies of the namespace hierarchy), but in. NET multi-project solution, the storage can be separated into similar data access layer only by means of interface separation.

　　2. Improved DDD tiering:

Evaluation: The infrastructure layer has the characteristics of shared layer and implementation layer at the same time. The advantage is to finally do the formal domain as the core and at the same time solve the infrastructure layer in the implementation of warehousing can not reference the domain model of embarrassment, the disadvantage is that there is no distinction between sharing and implementation of the concept.

　　3. The latest DDD tiering:

　　Evaluation: The advantage is that this is true to the core of the domain, no longer need for the infrastructure layer can not refer to the domain layer and then again in the service layer adaptation. Use the dependency inversion principle to completely invert the dependencies of specific technologies. Disadvantage, dependency inversion applied over the head, but also in a single project solution without problems, but in. NET multi-project solutions lead to bidirectional dependencies in formal namespaces. Basically, the infrastructure layer has no reuse value as the 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 share layer to the diagram as needed.

Four. Trends in the architecture:

(1) Taking the business logic as the core, paying more attention to the business logic.
(2) Dividing the specific dependencies of the business logic layer into one level unified management.
(3) More emphasis is placed on reducing dependencies within the solution than on the code reuse between solutions.
(4) The separation of shared layer and implementation layer will be more and more embodied. For example, onion-type architecture.

The above is about. NET logic structure of the simple introduction, I hope to help you learn.