Microsoft nlayerapp case theory and practice-DDD, distributed DDD and its hierarchy

I have been busy with my work for a while, and I haven't updated my blog for a month. From now on, I will continue to discuss the Microsoft nlayerapp case. I hope you will continue to pay attention to the Microsoft nlayerapp case, architecture design, and DDD.

In terms of architecture, Microsoft nlayerappProgramSuch an application architecture design provides a series of design guidelines. The so-called "complex business system application" refers to such a type of business system application, which has a relatively long life cycle. In its life cycle, there will be some predictable "revolutionary changes" (for example, upgrading or replacing the version of the technology/framework used), so later maintenance will become very important. Therefore, we should design such applications to minimize the impact of such changes on other parts of the application, for example, we need to ensure that infrastructure changes based on the infrastructure layer do not affect the upper layer of the infrastructure. More specifically, the domain model part of an application should focus only on the domain itself. Changing the other part of the application will not affect the domain model. In "complex business system applications", the behavior of business rules (that is, "Domain logic") will change frequently. Therefore, it will be very important to make the modification and testability well. To achieve this effect, we need to decouple the domain model part from the rest of the system. As part of the domain-driven design (DDD), domain-Oriented Multi-layer distributed architecture focuses on this issue.

in that case, DDD is not just an architecture + mode. Ddd is a way to develop applications and a way for teams to work in projects. According to DDD, the project team needs to cooperate in a special way and should be able to communicate directly with field experts (usually customers. The entire team needs to use the "general language", a language that everyone can accept, and so on. However, this case does not contain this content because it is a "process" or an ALM. Therefore, if you really want to practice DDD in 100%, you need to read the book domain-driven design-core complexity of software written by Eric Evans, or other books that discuss the DDD process will give a detailed introduction to the DDD process, project, and team, not just about the architecture and model. Architecture and pattern are only a small part of DDD, and what we show here is exactly this part. In short, we must emphasize that DDD is not just an architecture + model.

InCommunityMany of my friends think that the DDD architecture (classic or cqrs) has some problems in the application and promotion of actual projects, for example, during the transition from the old system to the new system, it is difficult to find the starting point for the ddd-style architecture. For example, the application system based on the cqrs architecture is difficult and complex, it is difficult for common developers to grasp relevant knowledge in a short period of time. Once a team flow occurs, new team members cannot be competent for development positions within a short period of time, affecting the project. Many of my friends are paying attention to the field-driven design and cqrs architecture, maybe from my blog SeriesArticleI was inspired, so I hope that I can use the idea and technology of DDD in my actual work and projects for development. But I encountered many obstacles in the application process and finally had to give up. For me, I focus on. NET technology and DDD, I have been exploring the architecture of a certain type of application, and try to show this design idea and architecture style to everyone. Note that the wording of "One Type" here is that the ddd-style architecture does not apply to all actual projects and application systems. As far as the software team itself is concerned, the development process of DDD implementation is not a matter of time. Architects need to analyze the actual situation of the project, including the architecture of the application system and various factors of team building (for example, can the team first introduce the agile development process, to adapt to the development mode of DDD, and so on ). The DDD process and the ddd-style architecture model are just another option. The following introduction may help you make more accurate choices.

Reasons for not choosing a domain-Oriented Multi-layer distributed architecture (ddd-style architecture)

If an application is relatively simple, and the technology and framework used by the infrastructure and business logic layer will not change much throughout its lifecycle, you do not need to use a multi-layer distributed architecture based on DDD. You can choose some rad (Rapid Application Development) technologies, such as WCF Ria services or Visual Studio lightswitch, which can make simple application development very efficient. These simple applications focus on time to market (TTM), but are not very concerned about reasonable structures, hierarchical decoupling, and other concepts. Generally, we turn such an application into a "data-driven application ".

Reasons for choosing a domain-Oriented Multi-layer distributed architecture (ddd-style architecture)

If you want your applications to adapt to changes in the business logic for a long period of time, we strongly recommend that you use a domain-Oriented Multi-layer distributed architecture. In this case, the domain model will reduce the high cost caused by changes in business logic, and the structure of low coupling between components and between layers, this allows you to isolate the domain model for adjustment and testing every time a business logic change occurs, without changing the rest of the application, this effectively reduces the development risks caused by demand changes and reduces project costs.

Distributed DDD (Distributed DDD, dddd)

This concept is mentioned by Microsoft nlayerapp in its guide book. It includes distributed features based on the DDD architecture. In Eric Evans's 《Domain-driven design-solutions to core software complexityIn his book, he didn't mention much about distributed technology (such as Web Service technology), mainly because the discussion on DDD is also based on domain. However, distributed technology is essential to the implementation and deployment of applications. In fact, Microsoft nlayerapp is oriented to distributed DDD and adopts Microsoft-specific technologies, such as WCF, in the process of implementing "distributed. Dddd also enables applications to better adapt to distributed scenarios, and even makes it easier to deploy applications in cloud computing environments.

Domain-Oriented Multi-layer architecture

As early 《Entityframework-driven design practices (2): layered architectureIn this article, I will introduce the layered architecture based on the DDD style. Now let's look back at it. The DDD architecture consists of four layers: presentation layer, application layer, domain layer, and infrastructure layer:

Now let's compare the structural hierarchy of Microsoft nlayerapp. The following layered architecture diagram is provided in the Guide Book of Microsoft nlayerapp. the layered architecture is basically the same as described above. At the same time, the internal layers are described in detail, this helps you better understand the components contained in each layer and their collaboration methods.

Understanding the overall architecture of the entire project is of great help in understanding the operating methods of the entire system. Next, I will introduce each layer in the above architecture. Let's see which components are included in these layers and how these components work together.

• Presentation): This layer displays necessary data information on the user interface and receives user feedback. The components in this layer mainly implement user interface functions such as graphic interface, user operation capture, and data forwarding. We recommend that you use the relevant mode (such as MVC, MVP, or mvvm) based on the actual situation of the project to segment these components into smaller layers.
• Distributed service layer): When an application provides business functions to other remote applications in the form of a service provider, or the client of the application is deployed in another remote location, its business logic must be released to the outside world through the distributed service layer. The distributed service layer (usually implemented as a Web Service) can provide remote access for applications based on configurable communication channels and data message formats. It should be noted that the distributed service layer should not contain any business logic implementation.
• Application Layer) The application layer is used to coordinate the work of the domain model and other application components to complete a specific and clear system task. Such coordination can include: Transaction Scheduling, uow ( Unit of work , Poeaa), and call some system-required processing tasks. The application layer can also include application optimization, data forwarding, and format conversion. Of course, we collectively refer to these tasks as "task scheduling". As for the core part of each task, the application layer will forward it to the lower layer for processing. The application layer is often seen as a "business facade", but it is not just as simple as forwarding requests/feedback at the domain model layer. It can usually contain the following content:
  • access the persistence layer mechanism through the repository contract to read or save domain objects. Note that the warehousing contract is accessed here, rather than the specific implementation of warehousing. The specific implementation of warehousing is the content of the basic structure layer
  • organize and organize data from objects in different fields so that the distributed service layer can transmit the data more effectively. Generally, data is organized in data transfer object , poeaa, for example, data contracts of WCF
  .
  • manage and maintain the state of the application (rather than the State of the domain object in the domain model)
  • coordinates the collaboration between domain objects, domain models, and infrastructure layer components. For example, in the bank transfer system, when funds are transferred from one account to another, you must first read the "Account" domain object through warehousing, then, transfer money on the domain object (it can be the behavior of the "Account" itself, or it can be, using domain service as an example of Evans )). After the transfer is completed, you may need to send emails whether the transfer is successful or not. This requires the collaboration of the basic layer of email components
  • application services: Pay attention to the fact that the services mentioned in DDD are not the same as the Web services that we usually call, it can exist at the application layer, domain model layer, or even basic layer. In DDD, the concept of service is actually a set of operations that cannot be attributed to any object. Therefore, service is usually used to coordinate the work between different objects. The same applies to application services. It coordinates other underlying components (such as the domain model layer and infrastructure layer).
  • business workflow: A business workflow is not mandatory. Introducing a business workflow to a business process composed of specific steps simplifies the problem.
• Domain Model Layer): This layer is mainly responsible for displaying business/domain logic, business processing status, and implementing business rules. It also contains the status information of domain objects. This layer is the core part of the entire application. It can contain the following concepts and content:
  • Entity)
  • Value objects)
  • Domain services)
  • Warehousing Contract/interface (repository contracts/interfaces)
  • Aggregates and factories)
  • Aggregate roots)
  • Specifications)
• Infrastructure layer (data persistence) : This layer provides services for data access of applications. It can be a persistence mechanism of applications, or 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 layer in a "low coupling" manner. Therefore, this layer can contain the following content:
  • specific implementation of warehousing: in terms of concept, "warehousing" means centralized management of a group of objects of the same type, just like warehouse that accesses the same type of objects. However, in practice, warehousing is mainly used to read and save objects in a specific persistence mechanism/technology. These persistence mechanisms/technologies can be Entity Framework, nhib.pdf, or ADO. NET components for a database engine. For the sake of simplicity, we concentrate Data Access operations into warehousing and develop a specific implementation of warehousing based on different persistence mechanisms/technologies, this will facilitate the maintenance and deployment of applications. During Warehousing Design, the common practice is to divide and aggregate Domain Models and differentiate the aggregation root. Then, a warehouse is designed for each aggregation, and the warehousing is managed by the aggregation root. In the domain model layer, each component accesses the warehouse through the warehouse contract (interface, in this way, the domain model layer does not need to understand the specific implementation and persistence details of any warehousing (persistence ignorance ), for more information, see entityframework-Based Domain-driven design practices (8) . In addition, what we usually call "Data Access Object" is not a warehouse. First, the warehouse is responsible for reading and storing the whole aggregation through the aggregation root, it is a concept of a domain, while a data access object directly performs database operations on a single object (more specifically a single data structure). Second, the operation methods are also different, the Warehouse will mark the objects in the memory before submission, and the last submission process ( unit of work , poeaa) is completed in the upper layer components (such as at the application layer)
  • Layer supertype (Layer supertype(Poeaa): Generally, when implementing specific functions of a layer, we extract the public logic of a series of objects and place these logics in an abstract type, at the same time, other types are inherited from this abstract type to avoid logical duplication. Such an abstract type is called a layer supertype. Most data access tasks can use layer-over-types to simplify development and reduceCodeMaintenance cost. For example. when accessing the database components of. net, we can use objects such as dbconnection and dbcommand to implement public logic in the layer-over-type, then inherit these logics in the subclass and provide specific sqlconnection, sqlcommand, oledbconnection, and oledbcommand instances.
  • Data Model: If you use ORM to implement warehousing, the orm usually uses a data model (such as Entity Framework) to implement the required functions, such a data model is a bit like an entity model, but like a data transmission object, it is completely different from the entity model at the domain model layer. Data Models are even visualized graphical descriptions maintained by specialized visual design tools.
  • Remote/External Service Proxy: When an external system is used for data persistence, the remote/External Service proxy is responsible for connecting to the external system and forwarding data operation requests and response information.
• Cross-cutting): This layer provides a general technical framework that can be accessed by other layers, such as exception capture and processing, logs, authentication, authorization, verification, tracking, monitoring, and caching. These operations are usually distributed horizontally at all layers of the application. We usually discuss the Aspect-oriented programming (AOP) the focus is on how to implement these cross-cutting functions without affecting the processing logic of the object itself. In practice, some popular interception frameworks (such as Microsoft unity and Castle dynamicproxy) can help us easily implement AOP.

Summary

This article focuses on text description and combines the Microsoft nlayerapp project to describe in more detail the DDD and its layered architecture. In this article, many 《Enterprise Application Architecture Model (poeaa)The concepts and Model names introduced in this book help readers better understand the main responsibilities of each layer in the DDD layered architecture. And 《Microsoft nlayerapp case theory and practice-multi-layer architecture and Application System Design PrinciplesThrough these two articles, we have learned a little about the application design and architecture, as well as the ddd-style architecture and its hierarchy. Starting from the next chapter, we will combine the layered architecture described in this article with the Microsoft nlayerapp project to further learn the specific implementation of the Microsoft nlayerapp project.