Summary of .net logical layered architecture

1. Basic knowledge preparation:

　1. Principles of layers:

　 (1) Each layer uses an interface for 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 uses the domain model by default
　 (2) The data access layer needs to reference the domain model by default

　 2. Layered architecture

　 The three basic levels 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 This model 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. It has obvious data-driven ideas and does not take the domain as the core.

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

　 Evaluation: NopCommerce adopts this model. Even if the service layer is separated and the resource library naming method is adopted, NopCommerce is not a DDD layer. The architecture is just a common 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 reuse value of the infrastructure layer is increased. 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 formal dependencies at the namespace level), However, in the .NET multi-project solution, the warehousing implementation can only be separated into a data access layer-like method 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 it finally achieves the formal domain as the core and at the same time 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, and 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. Disadvantages: 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 shared layers to the above image as needed.

4. Architecture trends:

(1) With business logic as the core, 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.

　　Reference

　　1.Patterns of Enterprise Application Architecture [Enterprise Application Architecture Pattern]
　2.Domain-Driven Design [Domain-Driven Design: How to deal with the core complexity of software]
　3.Applying Domain-Driven Design and Patterns【Field Driver design and pattern practice】
　4.Implementing Domain-Driven Design【Implementing domain-driven design】
　5.Microsoft Application Architecture Guide【Microsoft Application Architecture Guide (2nd Edition)】
　6.Professional Enterprise .NET【Proficient in .NET enterprise Project development: the latest patterns, tools and methods]
　　7.Professional ASP.NET Design Patterns [ASP.NET design patterns]