Summary of. NET Logical Layered Architecture,. net layered architecture

Summary of. NET Logical Layered Architecture,. net layered architecture
I. Basic Knowledge preparation:

1. layer principles:

(1) Each layer is called by the upper layer in interface mode.
(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) application logic.
(2) domain logic.

3. 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: Provides interface implementation.

4. Conventions:

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

Ii. Layered Architecture

Three basic layers of the layered 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 business logic classification, the layer is extended to four layers: presentation layer, service layer, Domain Layer and data access layer. The data access layer generally has to understand the domain model, which will generate two-way dependency between layers. We usually have the following two solutions:

1. Place the domain model on the sharing layer:

Rating: PetShop adopts this model, but it has many disadvantages: the business logic layer is not sub-real, the domain model is actually a data model, maintains the layer-to-layer dependency, and introduces more dependencies and obvious data-driven ideas, the domain is not the core.

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

Rating: NopCommerce adopts this model. Even though the service layer is separated and the resource library naming method is adopted, NopCommerce is not a DDD layered architecture, only a common three-tier architecture that adopts the domain model and interface separation principle. Disadvantage: Apart from data properties, other specific technical dependencies are not separated from the business logic layer.

Iii. DDD hierarchy:

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

1. Original DDD layering:

Evaluation: The advantage is that specific technologies are separated from each other and the value of reuse at the infrastructure layer increases. The disadvantage is that the infrastructure layer is not subdivided using the concept of sharing and implementation, which leads to reverse dependency when warehousing is implemented in the infrastructure layer, although there is no impact in the single-project solution (only dependencies in the namespace hierarchy form. in the. NET multi-project solution, the warehousing can be implemented independently by means of interface separation, similar to the data access layer.

2. Improved DDD layering:

Rating: the infrastructure layer features both the shared layer and the implementation layer. The advantage is that it has finally achieved the core of the formal field and solved the embarrassment that the field model cannot be referenced in the warehousing at the infrastructure layer. The disadvantage is that there is no concept of distinguishing between sharing and implementation.

3. The latest DDD layering:

Review: The advantage is that this is truly a domain-centric architecture, and it is no longer necessary for the infrastructure layer to reference the domain layer and to adapt to the service layer again. The dependency inversion principle is used to thoroughly invert the dependencies of different layers on specific technologies. Disadvantages: the Dependency inversion application is out of the header, and there is no problem in the single-project solution, but in the. NET multi-project solution, two-way dependency in the namespace form will be caused. Infrastructure layer as the Implementation Layer basically has no value for reuse. A better way is to change the positions of the user interface layer and infrastructure layer in the diagram.

You can add an appropriate sharing layer as needed.

Iv. Architecture trends:

(1) focus on the business logic and pay more attention to the business logic.
(2) divide the specific dependencies of the business logic layer into one layer for unified management.
(3) Pay more attention to reducing dependencies in solutions rather than reusing code between solutions.
(4) the separation of the Sharing layer and the implementation layer will be increasingly reflected. For example, an onion-type architecture.

Reference

1. Patterns of Enterprise Application Architecture [Enterprise Application Architecture mode]
2. Domain-Driven Design [Domain-Driven Design: The Way to cope with software core complexity]
3. Applying Domain-Driven Design and Patterns [field-Driven Design and pattern practice]
4. Implementing Domain-Driven Design [Implement Domain-Driven Design]
5. Microsoft Application Architecture Guide [Microsoft Application Architecture Guide (version 2nd )]
6. Professional Enterprise. NET [proficient in. NET Enterprise Project Development: the latest model, tools, and methods]
7. Professional ASP. NET Design Patterns [ASP. NET Design mode]