Analyzing .NET logical layered architecture

1. Basic knowledge preparation:

1. Principles of layers:

(1) Each layer starts with Interface method is used by the upper layer to call.
　(2) The upper layer can only call the lower layer.
　(3) Dependencies are divided into two types: loose interaction and strict interaction.

　2. Business logic classification:

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

3. Layers adopted:

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

4. Agreement:

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

2. Layered architecture

The three basic layers of the layered architecture are: presentation layer, business logic layer and data access layer. If the business logic layer is decomposed 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. The data access layer generally must understand the domain model, which will create two-way dependencies between layers. Usually we have the following two solutions:

1. Place the domain model in the shared layer:

## Evaluation: PetShop adopts this model, but it has many shortcomings: the business logic layer is not worthy of its name, and the domain model is actually a data model, which maintains inter-layer dependencies and introduces more dependencies. , the obvious data

driven idea is not domain-centered.

2. Define the data access interface in the business logic layer:

## Evaluation: NopCommerce adopts this model, even if it is separated The service layer has been removed and the resource library naming method has been adopted. However, NopCommerce is not a DDD layered architecture, but an ordinary three-tier architecture that adopts the principles of domain model and interface separation. Disadvantages: Apart from data real estate, no other specific technical dependencies are separated from the business logic layer.

3. DDD layering:

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

1. Original DDD layering:

## Evaluation: The advantage is that the specific technology implementation is separated from the domain, and the infrastructure layer Increased reuse value. The disadvantage is that the concept of sharing and implementation is not used to subdivide the infrastructure layer, resulting in reverse dependencies when implementing warehousing in the infrastructure layer, although it has no impact in a single-project solution (only the namespace

level formal dependency), but in a .NET multi-project solution, the warehousing implementation can only be separated into something similar to the data access layer through interface separation.

2. Improved DDD layering:

## Evaluation: The infrastructure layer has the characteristics of both the sharing layer and the implementation layer. The advantage is that the domain is finally formally the core and it also solves the embarrassment of not being able to reference the domain model when implementing warehousing in the infrastructure layer. The disadvantage is that there is also no distinction between the concepts of sharing and implementation.

3. The latest DDD layering:

## Evaluation: The advantage is that this is truly domain-centric. There is no need to adapt again in the service layer because the infrastructure layer cannot reference the domain layer. Use the dependency inversion principle to completely invert the dependencies of each layer on specific technologies. Disadvantage: Dependency inversion is applied too much. It is also no problem in a single-project solution, but in a .NET multi-project solution it will lead to bidirectional dependencies in the form of namespaces. As the implementation layer, the infrastructure layer basically has no reuse value. A better approach is to swap the positions of the user interface layer and the infrastructure layer in the diagram.

You can consider adding appropriate sharing layers to the above picture as needed.

4. Architecture trends:

　(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 for unified management.
　(3) Pay more attention to reducing dependencies within solutions rather than code reuse between solutions.
　 (4) The separation of the sharing layer and the implementation layer will be increasingly reflected. For example, onion architecture.

The above is the detailed content of Analyzing .NET logical layered architecture. For more information, please follow other related articles on the PHP Chinese website!