Standard tiered architecture for domain-driven design

Presentation user interface/Presentation layer

Responsible for presenting information to users and interpreting user commands. In a more granular way, it is:

1. Request the application layer to obtain the data that the user needs to show;

2. Send the command to the application layer to require it to execute a user command;

Application Application Layer

A thin layer that defines all the tasks the software needs to accomplish. External to the presentation layer to provide a variety of application functions (including queries or commands), internal calls to the domain layer (domain objects or Domain Services) to complete a variety of business logic, the application layer does not contain business logic.

domain Domain layer

Responsible for expressing business concepts, business status information and business rules, the domain model is at this level and is the core of the business software.

Infrastructure Infrastructure Layer

This layer provides common technical capabilities for other tiers, provides inter-layer communication, implements persistence mechanisms for the domain layer, and, in short, the infrastructure layer can support the technical needs of other tiers through architecture and frameworks;

================================================================
presentation Layer (Presentation): The primary responsibility of this layer is to display the necessary data information to the user through the user interface, while receiving feedback from the user. The components in this layer mainly implement user interface functions such as graphical interface, user operation capture, data forwarding and so on. It is recommended that these components be subdivided into smaller tiers based on the actual project, using relevant patterns (such as MVC, MVP, or MVVM).Distributed Services Tier (distributed service layer): When an application provides business functionality to other remote applications in the form of service Provider, or if the client of the application is deployed to another remote location, its business logic must be published to the outside world through a distributed service layer. The Distributed service layer, which is typically implemented as a Web service, provides remote access to applications based on configurable communication channels and data message formats. It is important to note that the distributed service layer should not contain implementations of any business logic.application tier (Application layer): The application layer is used to coordinate the work of the domain model and other application components to accomplish a specific, clear system task. This coordination can include: Transaction scheduling, UoW (Unit of work, POEAA), as well as invoking some of the system's required processing tasks. The application layer can also include application optimization, data forwarding and format conversion, of course, we refer to these work as "task scheduling", as to the core of each task, the application layer will be forwarded to the lower processing. The application layer is often seen as a "business-layer look-and-facade", but it is not simply the process request/feedback of the forwarding domain model layer. It can usually include the following: access the persistence layer mechanism through the warehousing contract (Repository contract) to read or save the domain object. Note that this is the warehousing contract, not the specific implementation of warehousing. The concrete implementation of warehousing is that the content of the infrastructure layer organizes and collates data from different domain objects to enable the Distributed service layer to deliver the data more efficiently. In general, we will organize the data in the Transfer object (Data Transfer Object, POEAA), such as data contracts for WCF, manages and maintains the state of the application (rather than the state of the domain object in the domain model) to coordinate the collaboration between the domain objects, the domain model, and the infrastructure layer components. For example, in a bank transfer system, the transfer of funds from one account to another, the first need to read the "account" domain object through warehousing, and then transfer operations on the domain objects (can be "account" itself behavior, or, by example, Evans, the use of Domain Services (domain Service)). Perhaps after completing the transfer, whether successful or not, you need to send out e-mail, which requires the infrastructure layer's e-mail component to collaborate on the application Service (application services): First of all, the services mentioned in DDD and the usual web Service is not a concept, it can exist in the application layer, the domain model layer or even the infrastructure layer. The concept of service in DDD is, in fact, a collection of operations that "cannot be attributed to any one object", so the service is usually coordinating the work between different objects. The same applies to the application service, which coordinates the business workflow with other lower-level components (such as the domain model layer and the infrastructure layer): Business workflows are not required, and for some business processes consisting of specific steps, the introduction of a business workflow can make the problem easier.Domain Model Layer: The primary responsibility of this layer is to present the business/domain logic, the business processing state, and the implementation of the business rules, which also contain the state information of the domain objects. This layer is a core part of the entire application and can contain these concepts and content: Entity (Entities) Value object (value Objects) domain service (Domain Services) warehousing contract/interface (Repository contracts/ Interfaces) Aggregation and its factory (aggregates and factories) aggregation root (Aggregate Roots) Protocol Object (specifications)infrastructure Layer (Data Persistence section) (Persistence Infrastructure layer): This layer serves the application's data access, either as a persistence mechanism for the application itself, or as a Web service for data access provided by external systems. Based on the design principles of the layered architecture, the layer should provide data persistence services to the upper layers in a "low-coupling" manner. Therefore, the layer can contain the following: the specific implementation of warehousing: Conceptually, "warehousing" means that a group of objects of the same type is centrally managed, as if it were a repository to access the same type of object. In practice, however, warehousing is primarily used to perform read and save operations on specific persistence mechanisms/technologies. These persistence mechanisms/techniques can be an entity Framework, NHibernate, or an ADO component for a database engine. For simplicity, we centralize data access operations into warehousing and develop a specific implementation of warehousing for different persistence mechanisms/technologies, which makes it easy to maintain and deploy applications. When designing warehousing, it is common practice to first divide the domain model into aggregations and differentiate the aggregation root, and then design a warehouse for each aggregation, which manages the aggregation through the aggregation root. In the domain model layer, the components are accessed through warehousing contracts (interfaces), which makes it unnecessary for the domain model layer to understand the specific implementation and persistence details of any warehousing (persistence ignorance), and readers can refer to theentityframework Field-driven design practice (eight)"article. In addition, the "Data access object" We usually talk about is not warehousing, first of all, warehousing through the aggregate root, responsible for the entire aggregation of read and storage, it is a domain concept, The data Access object is a single object (more specifically a single data structure) of the database operations directly, and secondly, the operation is also different, the storage will be in memory before committing the object, the last commit process (Unit of work, POEAA) is a layer super type that is completed in the upper component (for example, in the application layer) (Layer supertype, POEAA): In general, when implementing a specific function of a layer, we extract the common logic of a series of objects and then place them in an abstract type, while allowing other types to inherit from the abstract type to avoid logical duplication. Such an abstract type is called a layer super type. Most data access tasks can use layer hyper-types to simplify development and reduce code maintenance costs. For example, when implementing a database access component for ADO, we can implement common logic in a layer superclass using objects such as DbConnection, DbCommand, and then inherit those logic in subclasses and provide specific SqlConnection, SqlCommand or OleDbConnection, oledbcommand instance data model: If you use ORM to implement warehousing, the ORM will typically use a data model (such as entity Framework) To implement the required functionality, such a data model is a bit like a solid model, but it is exactly the same as the data transfer object, which is completely different from the entity model of the domain model layer. The data model is even a visual graphical description that is responsible for maintaining remote/external service proxies by a dedicated visual design tool: When using an external system to implement a data persistence mechanism, the remote/external service agent is responsible for connecting to the external system and forwarding the data operation request and response informationinfrastructure Layer (cross-cutting): This layer provides a common technical framework that can be accessed by other layers, such as exception capture and processing, logging, authentication, authorization, authentication, tracking, monitoring, caching, and so on. These operations are often spread horizontally across all levels of the application, and the aspect-oriented programming (AOP) We discuss in general is about how to implement these crosscutting but essential functional points without affecting the processing logic of the object itself. In practice, using some popular interception frameworks (such as Microsoft Unity, Castle dynamicproxy, etc.) can help us to implement AOP easily