. Net domain-driven design-how to use the design pattern to subvert the traditional architecture

Reading directory:

• 1. Introduction
• 2. Briefly understand the reason (the preliminary issues in this article)
• 3. domainmodel Scalability (design model change points using design patterns)
  • . Model scalability
  • . Use of the design pattern (the design pattern and design ideology developed by painstaking research can be freely used)
  • 3. Use of partial categories (encapsulate internal objects)
  • . High-Intensity OO design (highly abstract design for specific fields forms a framework for specific fields)
• 4. domainmodel business logic rule configuration (remove extension points and use appropriate configuration to import the rule IOC)
• 5. Summary of DDD (what is DDD? It is "tactical ")

1. Introduction

This article won't be too long, but it definitely gives you a more intuitive understanding of DDD;

Although the content mentioned in this article is not much, it is not easy to comprehend (because most people still have many misunderstandings about DDD). Of course, it is not a magical thing, it's just a small experience that I have been studying DDD recently. The design methods mentioned in this article have great advantages, you will find that it is the most obvious difference from the traditional three-tier architecture, which is also the most classic advantage and the most valuable place;

This article was originally "[stick]. net domain-driven design-Practice (going bright through the fog) "is part of the article, but due to the time relationship, the complete example is not released in sync with the article. To tell the truth, the time is too tight, the purpose of writing examples is to give a comprehensive and detailed explanation of the best practices of DDD analysis and design. I originally wanted to publish the examples in the article, however, due to work relationships and some private reasons, I may not update my blog for a while, and I don't want this article to be dragged on for too long. So I have summarized two valuable points to share with you, the purpose is not to allow everyone to use DDD to design the system, but to have a breakthrough point to measure where DDD is better than the traditional three-tier architecture, because most people do not have the development experience of DDD, there should be no relevant means;

Many of the DDD articles on the Internet are still quite good, but I have a general understanding of DDD since I have no idea about it, I think the biggest problem is to allow those who are not in touch with DDD to better understand where DDD is, rather than a wide array of theories and some UML model diagrams; in fact, the complete example is only the two most valuable points, because it is the center emphasized by DDD;

2]. A brief understanding of the reason (the preliminary issues in this article)

Before proceeding to the following sections, let's take a look at the design we are going to do. I suppose you don't have time to read "[stick]. net domain-driven design-Practice (going bright through the fog) "is a bit long, so here we will briefly introduce the continuous content;

In this article, we will use two conventional Framework Design Methods to design fine-grained decomposition of core services. In the past, this was very difficult to implement. So why should I talk about the framework design idea, because our application of the design model is mainly on the infrastructure with non-business needs such as the framework and components, here we will use these powerful weapons to design the most difficult to deal with business scalability;

All the business in this article is actually a simple background for studying the examination system. We will use the powerful design capabilities[Employee]Aggregation is used for fine-grained design and configuration. The previous design is complete, and data persistence is also completed, leaving the coding stage. The biggest challenge of coding lies in the design of related interfaces in the early stage, here is the fine-grained interface design, rather than simple layering;

Figure 1:

I marked the "employee" aggregation to be extended below with red circles. After the model is implemented into the code, we will use the Protocol mode to visualize the "employee" verification, then, the rule is strategized through the Policy mode of the design mode, and then the configuration of all the business rules is managed through the routing aion manager. At this time, IOC will be used, and everything will work well; you cannot do the traditional three-tier architecture;

See the following [employee] entity class code:

/* ===================================================== ========================================================== * Author: deep training * Create Time: 2013-07-08 * blog address: http://www.cnblogs.com/wangiqngpei557/ * Author Description: software engineering practices in specific fields; * ===================================================== ======================================================= * /namespace domain. domainmodel. examinationmodule. aggregates. employee {using system; using system. collections. generic; using domain. domainmodel. approvemodule. aggregates. parentmesagg; using domain. domainmodel. examinationmodule. aggregates. fieldexaminationdomains; using domain. seedwork; public partial class employee: entityobject {public employee () {This. parentmessage = new hashset <parentmessage> (); this. teachercheckgroup = new hashset <teachercheckgroup> ();} Public String Eid {Get; set;} Public String ename {Get; set;} public nullable <employee_marry> ismarry {Get; set;} public nullable <int> Age {Get; set;} Public String username {Get; set;} Public String password {Get; set ;} public nullable <employee_switch> switch {Get; set;} public nullable <employee_role> emprole {Get; set;} public nullable <employee_sex> sex {Get; set ;} public Virtual icollection <parentmessage> parentmessage {Get; set;} Public Virtual icollection <teachercheckgroup> teachercheckgroup {Get; set;} public void reswitch () {If (this. switch. value = maid) This. switch = employee_switch.isture; else this. switch = employee_switch.isfalse;} public void reinitial () {Password = "000000 ";}}}

 

[Employee] aggregation is not much different from general aggregation. It is a simple structure. To make it look complete, I have added two initialization actions. reswitch is used to enable and disable the current account;

Reinitial is the initial default password for initializing the current [employee]. It is used for demonstration purposes;

So what should we do next? In the "employee" as the aggregation root, we aggregate the "parentmessage" parent message and the "teachercheckgroup" station test. These two sets are actually used for navigation attributes; the Entity Framework needs this information for entity navigation. during design, you need to weigh how many such associations you need;

The following changes may occur after in-depth analysis of the requirements:

After [parent] sends a message to [employee Instructor], the instructor needs to give feedback on the message content, for example, to [reply promptly ], different levels of messages must be handled;

This requirement is simple, but what does it reveal? Design scalability. Where is the scalability? Different [processing] needs to be given for different [Message levels], which is obviously a point that may change at any time;

[Employee_priority] Code:

/* ===================================================== ========================================================== * Author: deep training * Create Time: 2013-07-08 * blog address: http://www.cnblogs.com/wangiqngpei557/ * Author Description: software engineering practices in specific fields; * ===================================================== ======================================================= * /namespace domain. domainmodel. approvemodule. aggregates. parentmescript {using domain. domainmodel. examinationmodule. aggregates. employeemessage; using system; public partial class parentmessage {Public String pmid {Get; set;} Public String PID {Get; set;} Public String Eid {Get; set ;} public String content {Get; set;} public nullable <message_priority> priority {Get; set;} public nullable <system. datetime> datetime {Get; set;} Public Virtual employee Employee {Get; set;} Public Virtual parent {Get; Set ;}}}

There is a priority attribute that indicates the emergency of the message. Check the Code:

 

/* ===================================================== ========================================================== * Author: deep training * Create Time: 2013-07-08 * blog address: http://www.cnblogs.com/wangiqngpei557/ * Author Description: software engineering practices in specific fields; * ===================================================== ======================================================= * /namespace domain. domainmodel. examinationmodule. aggregates. employee {using system; public Enum message_priority: int {normal = 1, pressing = 2 }}

There are two levels: normal indicates normal, pressing indicates urgent, and urgent means must be handled first, and the processing logic is more or less different; all the business logic in DDD must be processed in the domainmodel layer. This is the principle; All logics are not directly used. For example, when logging on, we usually verify whether the user name and password are true, however, there are usually many other conditions, such as whether the current user is a senior member or not, and whether the user is in arrears, which are all obtained in the aggregation protocol factory, this makes it easy for us to design the Changed Points in special places;

The principle of logical judgment is that if \ else is not directly written, and the principle of logical processing is that implementation code is not directly written, and the strategy class is implemented through interfaces;

Figure 2:

 

We added a processing method for the [parentmessage] object in [employee]. Because our domainmodel is not directly persistent in membercache, therefore, operations with UI interaction cannot be directly used by objects. If it is an automated operation, no parameters are required for the method here. The message ID must be taken every time, then we can perform an internal search. Of course, we can also get the [parentmessage] instance in the application layer;

In fact, the fine-grained design has been started at this time. Let's take a look at the domainmodel structure;

Figure 3:

 

If it is database-driven, we cannot extract the related objects of [employee]. Some statuses are only numerical representation and lack oo ideas, so we cannot talk about object-oriented design; the most exciting thing here is that we can fully design the logic related to [employee] in fine-grained scalability, here we will put all the business logic related to [employee] into the dedicated employeelogic directory. There are many advantages, and the most relevant thing is the project task allocation, after the design is complete, some logic can be abstracted out and the interface can be allocated to someone for implementation;

This section mainly introduces the background. Next we will perform a high degree of analysis, design, and configuration on the business logic of [employee] processing [parentmesssage;

3] domainmodel Scalability (use the design mode to design model changes)

Model scalability is a focus that we have been paying attention to for countless times, and our grasp of it has never been realized. The traditional layered architecture fills all the business logic at every layer, from the UI Layer to the database, there are more or less business logic, rather than taking responsibility for each of them and managing their own classification. The UI Layer is mainly responsible for their own appearance, so don't get dirty here; databases should manage data storage, data optimization, and so on. Neither of them has the right to manage business logic;

Here we will use the design model to abstract the business logic that may change;

3.1] model scalability

In the above introduction, we generally understand the requirements. Next we will judge the priority attribute of [parentmessage], because these two priorities are different for business logic processing, however, there may be the same logic, which is completely in line with our OOA, oop center, and we can perform powerfulAbstraction,InheritanceThis is also the scope of OO management, which is not available in Ui \ database;

For example, DDD can be used with the UI and database:

Ui: I have nothing to do, so let me handle the business separately;

Database: I am very powerful, and all the data is under my management scope. I am the first in the world to handle what I want;

Ddd said: You can either listen to me from the very beginning, or you will not be able to manage anything later. -- Wang qingpei;

The design mode is very powerful, and there are many options to deal with current business problems. Here we use common"Policy mode"To solve the logic of different priority;

3.2] use of the design pattern (the design pattern and design idea carefully researched can be freely used)

I don't need to talk about the strength of the design model anymore. Everyone understands it. here we need to extract the logic processing into a specialized logic processing class, this is also in line with the principle of opening to the extension and changing to the closed;

The logic processing is independent, and there is a shadow re-labeling relationship with the domainmodel. Although the logic processing class is relatively independent, it is still in the field after all; the business logic is completely closed in the domain layer. However, in this layer, you still need to perform fine-grained Analysis and Design on specific services, it is not a small challenge for architects, because most architects focus on pure technologies and lack experience and interest in business analysis and design;

Let's take a look at the simple design of priority processing:

Figure 4:

The ideal design is interface-oriented. The [employee] entity does not depend on any specific implementation class;

Figure 5:

The processing logic of priority is abstracted from related policy interfaces.IparentmessageoperationThe interface has two interfaces to process specific business logic with different priorities;ParentmessageoperationnormalIs the logic for processing priority as normal,ParentmessageoperationpressingIt is the logic for processing priority as pressing. Of course, I added anotherAbstract
Calss parentmessageoperationbasicAbstract The same logic;

A simple priority logic can be designed in this way. I think that if the business analysis is good, there will be no problems with the design here; so far, I have been shocked by the power of DDD. I don't believe you have not seen how complicated it can simplify the problem. In the past, it was absolutely impossible to complete such a design, at least I have never seen or heard of anyone who can design complex business systems flexibly under the traditional three-tier architecture without compromising the UI and database;

If there is a policy interface, we have to bind the corresponding implementation class. There are two methods here. The first method is to use a simple interface to directly determine and then create a policy implementation, the second method is Dynamic Injection Using IOC. Of course, we are all very good at this point. If everyone's design ideas are different, there will be no nonsense;

Figure 6:

Looking at this structure, I didn't understand it, but DDD is not elegant. Here we are very clear. We use iparentmessageoperationfactory to create iparentmessageoperation. The specific logic is encapsulated in the implementation class dominated by iparentmessageoperation interface;

Figure 7:

 

We use iparentmessageoperationfactory to create iparentmessageoperation. Is it refreshing;

Figure 8:

The code here will hardly change as the business changes, but it should be changed in the logic processing;

Figure 9:

The processing logic method of the interface. It is very simple to define two entities: parentmessage and employee. Pay attention to balancing the associations between entities;

Figure 10:

Through the base class, you can abstract the public logic. This is used for demonstration. At this step, we all know how to design it. The key is to analyze the business, then we can draw a deep domain model. It is reliable to design it on this basis. Do not design it for the sake of design, and do not fall into technical difficulties;

Figure 11:

This figure shows our design of priority-related logic. There are two interfaces at the top layer, a factory implementation on the right, and an inheritance tree on the left, which is relatively simple;

3.3 Use of partial classification (encapsulate internal objects)

In many cases, we need to use partial classification to plan the relationship between objects so as not to pollute other entities. For example, here [employee] needs to use a specific type internally, therefore, it is best to put it in the [employee] and do not expose it outside. This is a reasonable design in the logic processing;

Figure 12:

The combination of internal classes and generic classes will play a great role in design, so we won't talk about it here;

3.4] high-intensity OO design (highly abstract design for specific fields forms a framework for specific fields)

From Section 3.3 above, we can understand that abstraction in specific fields is actually feasible, that is, a powerful framework and component oriented to specific fields will be formed in the end, however, such a framework is not universal, that is, the current domain model can be used, which is indeed costly for general projects and outweighs the cost; then, it is worthwhile to invest in projects, products, and e-commerce platforms that require long-term maintenance. Long-term reconstruction leads to a domain framework with strong cohesion;

Figure 13:

If a framework is universal, it can only be generic and cannot be used inside the business;

Figure 14:

In fact, it is to focus on specific fields and gradually reconstruct the frameworks of specific fields;

4] domainmodel business logic rule configuration (after separating extension points, use the appropriate configuration to bring rule IOC in)

In fact, it is no longer a big problem to reconfigure the business logic.IparentmessageoperationThe implementation class is configured through IOC. However, the configuration policy must be determined based on the business. Multi-dimensional judgment may exist to determine which implementation class to use, if the program is followed by the C #4.0 meta-programming, it can actually implement the runtime configuration logic strategy, but it is not very mature at present. We only need to first implement all the business logic, configure the backend based on business needs;

For example, the background management of the system automatically checks whether it is a day off. If it is a day off, there is no right for [employee] to execute the [parentmessage] processing. Is it very simple? Of course, many good designs can be moved to the system slowly, on the premise that"Restructuring specific fields-Framework Design in specific fields", This degree is well grasped;

5. Summary of DDD (what is DDD? It is "tactical ")

Recently discussed in the garden. NET technology is worth nothing. net or \ Java are both tools. combat tools must have a certain level of strategic design to make them play a specific role. DDD can be compared to Sun Tzu's Art of War ,. net is just a tool for war. So is Java. The key to Python and Ruby is design ideas and strategies. Therefore, we have been cultivating design capabilities for a long time, be familiar with a certain technology platform properly, so as to remain unchanged; Java is awesome, and it is rubbish if you don't understand the enterprise architecture ,. net is awesome, and you don't know the design pattern;

All technical frameworks have their advantages and disadvantages. We only need to first design and plan the overall architecture, and then use the appropriate technology in the appropriate place. This technology is good at this aspect, arrange it in this position ;. the net advantage lies in the development speed and ui, so it is used for front-end development. Java may have advantages in big data and distributed backend, so it is used for server development and search engines; ruby is a dynamic language that can be used to implement complex dynamic business configurations. It gathers the power of the family to complete a large battle. No one leaves and no one is more important than others, in a single battle, there is no shortage of fire fighters. Yang Wufeng, the only military engineer, is not confused. Thank you;

 

 

Author: Wang qingpei

Source:Http://blog.csdn.net/wangqingpei557

The copyright of this article is shared by the author and csdn. You are welcome to repost it. However, you must retain this statement without the author's consent and provide the original article connection clearly on the article page. Otherwise, you will be entitled to pursue legal liability.