. NET domain driven design-see how DDD uses design patterns to subvert traditional architectures

Read the catalogue:

• 1. Introduction
• 2. Simply understand the reason (the previous issue of this article)
• 3.DomainModel Extensibility (Design model change points using design patterns)
  • 3.1. Model Extensibility
  • 3.2. The use of design patterns (painstaking research of the design mode, design ideas can be used freely)
  • 3.3. Use of partial classes (encapsulation of internal objects)
  • 3.4. High-intensity OO design (highly abstract design for specific areas to form a specific domain framework)
• 4.DomainModel business Logic rule configuration (the rule IOC goes in with the appropriate configuration after separating the extension points)
• 5.DDD Simple Summary (what is DDD?) It's "tactical")

1 "Introduction

This article is not too long, but it definitely gives you a more intuitive endorsement of DDD;

The content of this article is not much, but it is not easy to understand (because most of the understanding of DDD is still a great misunderstanding,), of course, is not how magical things, but I have been studying the results of DDD a small experience to share with you This article is about these design methods in itself there is a great advantage, you will find it with the traditional three-storey architecture is the most obvious difference, which is the most classic advantage of the place, the most valuable place;

Originally this article is "[Top]." NET domain driven design-practice (through the fog to the Light) "part of the article but because of the time, the complete example is not in sync with the post, to tell the truth time is too tight, the purpose of writing an example is to fully and carefully explain the analysis of DDD, design the best practices of each link Originally wanted to make an example of the article in the post, but due to working relationship and some private reasons may not update the blog for some time, and do not want this article dragged too long, so I summed up two points more valuable places to share to everyone, not to let you can use DDD to design the system, But it can have a breakthrough point to measure how DDD is better than the traditional three layer, because most people do not have the development experience of DDD, so can realize that there should be no relevant way;

Many of the online DDD articles are still very good, but I also from the DDD to the current to have a whole understanding of DDD, feel the biggest problem is to let the friend can not contact DDD to the most appropriate experience of the DDD exactly where good, rather than a large number of theories on the theory of some UML model diagram In fact, the complete example is the only two points that are most valuable, because it is the center of the emphasis of DDD;

2 ". Simply understand why (earlier in this article)

Before starting the next section of this article, let's take a look at what we're going to do, and I'm assuming you don't have time to read "[Top]." NET domain driven design-practice (through the fog to the light) "article, the comparison is a bit long, so here is a brief introduction to the content of continuity;

In this article we will use two conventional framework design approach to the core of the business of fine-grained decomposition design, in the past it is difficult to achieve, so why I say the framework of design ideas, because we use the design pattern mainly in the framework, components of these non-business requirements of infrastructure So here we will use these powerful weapons to design the most difficult business extensibility;

This whole business is a simple study of the background of the test system, we will use a strong design capabilities to the "Employee" aggregation of fine-grained design, configuration, the previous design has all finished, data persistence is also designed to complete, leaving the coding phase The biggest challenge of coding lies in the design of the pre-related interface, which is a fine-grained interface design, not a simple sub-layer;

Figure 1:

(View larger image)

I use the red circle to mark the "employee" aggregation we want to extend below, after we have implemented the model into code, we will pass the "employee" validation object through the protocol pattern, then use the policy pattern of the design pattern to configuraion the rules and then Manager to manage all the configuration of the business rules, this time the IOC comes in handy, everything is easy; you can't do it on a traditional three layer;

Take a look at the following "Employee" entity class Code:

View Code

"Employee" aggregation is not much different from the general aggregation, relatively simple structure, in order to look complete, I added two initialization behavior; Reswitch is used to enable, close the current account;

Reinitial is the initial default password for initializing the current "Employee", which is completely demo-used;

So what are we going to do next? In the "Employee" as the aggregation root we aggregated "parentmessage" parents message, "Teachercheckgroup" station test, two sets, in fact, this is used to do navigation properties; The Entity Framework requires this information to be used for entity navigation, At design time you need to weigh how much of this connection you need;

There may be a change following our in-depth analysis of requirements:

"Parent Parent" to "Employee Teacher" "message", teachers need to feedback content, such as to "timely reply", for different "message level" need to give different treatment;

The demand is simple, but what does it reveal? The extensibility of the design, where is this extensibility? For different "message levels" need to give different "processing", it is obviously a possible change at any point;

"Employee_priority" code:

View Code

There is a priority attribute, which is the emergency case that marks the message, see the code:

View Code

There are two levels, normal is normal, pressing is urgent, must be dealt with urgently, and the logic of processing is more or less different; all business logic in DDD is handled in the Domainmodel Layer, which is the principle All the logic is not used directly, for example, we usually verify the username and password when we log in, but there are often many other conditions, such as whether the current user is a premium member, whether or not he is owed a fee, etc., which are obtained uniformly in the aggregator factory. This allows us to draw the point of change to a specific place for design;

Logical judgment of the local principle is not directly written if\else, the logical processing of the local principle is not directly write implementation code, through the interface to implement the policy class;

Figure 2:

We have added a handle to the "Parentmessage" entity in "Employee", because our domainmodel is usually not directly persisted in Membercache, so the operation with UI interaction is not very good for the direct use of the entity, If it is an automated operation here the method does not need any parameters, each time the message will need to bring the ID, and then we do the internal search, of course, here can also be in the application Layer on the "Parentmessage" instance can be put into the in also May;

In fact, this time has begun to be fine-grained design, we look at the Domainmodel structure;

Figure 3:

If it is a database-driven, we are unable to extract the "Employee" of the relevant objects, some state is only a digital representation of the lack of OO thinking, there is no object-oriented design; the most exciting thing about this place is that we've been able to put "employee" Related logic for fine-grained extensibility design, here we will all the "Employee" related to all the business logic into the dedicated employeelogic directory, the benefits are really many, the most relevant to us is the project assignment, So when the design is complete, some logic can be abstracted out of the interface and assigned to someone to realize it.

This section is mainly to introduce the relevant background, the following we will be "Employee" processing "parentmesssage" business logic to carry out a high degree of analysis, design, configuration;

3 "Domainmodel Extensibility (using design patterns to design model change points)

Model Extensibility is a focus that has been brought to our attention countless times, and the grasp of it has not been achieved; The traditional tiered architecture fills all the business logic at every level, from the UI layer to the database, with some business logic, not accountability, to manage what you classify, and the UI layer to be responsible for its own good looks, Don't get dirty in here. The database should be well-managed data storage, data optimization and so on, both have no right to control the business logic of the right;

Here we are going to design patterns by abstracting the business logic that may be changing;

3.1 "Model Extensibility

In the above introduction we probably understand the requirements, the following we want to "parentmessage" the priority attribute to judge, because these two priorities for business logic processing is different, but there may be the same logic, which is fully consistent with our OOA, The center of OOP, we can carry out a powerful abstraction , inheritance to deal with, this is the scope of our OO should be managed, ui\ database does not have such ability;

You can use DDD as a metaphor for the UI and database:

UI: I don't have anything to do with my business.

Database: I am very strong, all the data are within my management scope, I want to deal with how to deal with, I number one;

DDD said: Brothers, either from the beginning of the time you listen to me, otherwise what happened in the back, I can not control you;--Wang Qingbei;

The design pattern is very powerful, can handle the current business problem has many patterns to choose, here we use the common "strategy pattern" to solve the different priority logic;

3.2 "The use of design patterns (painstaking research design mode, design ideas can be used at will)

The power of the design pattern I don't need any more nonsense, we all know; so here we need to extract the logical processing into a specialized logic processing class, which also conforms to the extended open to modify the closure principle;

The processing of logic is independent, there is a shadow with the Domainmodel between the re-paste relationship, although the logical processing class is relatively independent at that time it is still in the domain class of things, the business logic is completely closed in the domain layer, but in this layer is not beard eyebrows cluth, Or the need for a granular analysis of the specific business, design, the architect is a big challenge, because most of the architects are more concerned about the pure technology, the business analysis and design lack of experience and interest;

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

Figure 4:

The ideal design is interface-oriented, "Employee" entity does not depend on which specific implementation class;

Figure 5:

Our processing logic for priority is abstracted from the relevant policy interface Iparentmessageoperation, which has two interfaces to handle the specific business logic of different priorities; Parentmessageoperationnormal is the logic that handles priority as normal,parentmessageoperationpressing is to deal with the logic of priority as pressing, of course, I added an abstract for the sake of later consideration.
CALSS parentmessageoperationbasic Do some abstractions of the same logic;

A simple priority logic can be designed in this way, I would like to complex business as long as the business analysis good, the design here is not a problem; So far I have been shocked by the strength of DDD, I don't believe you don't see how complex the problem it can simplify, The past is absolutely impossible to complete such a design, at least I have never seen or heard who can in the traditional three-tier architecture of the complex business system design is very flexible, and will not pollute the UI, database;

There is a policy interface then we have to tie up the corresponding implementation class, here are two ways, the first use simple interface directly to determine and then create a policy implementation, the second is the use of the IOC dynamic injection into the way, of course, here is the area we are all more adept at, Everyone's design thinking is different, not much nonsense;

Figure 6:

Looking at this structure, I did not understand that DDD was not graceful; it is clear that we are using iparentmessageoperationfactory to create iparentmessageoperation , the specific logic is encapsulated in the implementation class based on the iparentmessageoperation interface;

Figure 7:

We create iparentmessageoperation through iparentmessageoperationfactory, is not very refreshing;

Figure 8:

The code here almost does not change as the business changes, the change is in the logic processing inside;

Figure 9:

Interface processing logic method, it is simple to contract a "parentmessage", "Employee" two entities, here need to pay attention to the relationship between the balance of entities;

Figure 10:

Through the base class can be abstract point of public logic, here is to demonstrate and use; in fact, to this step we all know how to design, the key is to analyze good business, and then get the deep domain model, on the basis of design is reliable, not designed to design, do not fall into the technical dilemma;

Figure 11:

This figure is our priority related logic design, the top layer is two interfaces, the right is a factory implementation, the left is the operation inheritance tree, or relatively simple;

3.3 "Use of partial classes (encapsulation of internal objects)

In many cases, our design needs to use some of the classes to plan the relationship between objects, so as not to pollute other entities; for example, "employee" here needs to use a specific type internally, so it is best to put it inside "employee" and not expose the outer side. ; It is reasonable to design in logic processing;

Figure 12:

The inner class is combined with generics and will play a great design, and here is not a rip-off;

3.4 "high-intensity oo design (highly abstract design for specific areas to form a specific domain framework)

From the above 3.3 "section we can realize that the abstraction of a particular domain is actually feasible, that is to say, the end will form a strong domain-oriented framework, components, but such a framework is not universal, that is, the current domain model can be used, which is really costly for the general project, not worth And then for long-term maintenance of projects, products, e-commerce platform worthy of input, long-term reconstruction of a strong cohesive domain framework;

Figure 13:

If you have a framework to do the versatility of the function, can only be general, unable to penetrate into the business of the internal;

Figure 14:

In fact, focus on specific areas, and gradually reconstruct the framework of specific areas;

4 "Domainmodel business logic rule configuration (the rule IOC comes in with the appropriate configuration after separating the extension points)

In fact, it is not a big problem to configure the business logic, it is only necessary to configure the above iparentmessageoperation implementation class through the IOC, but this configuration strategy needs to be judged by the business. There may be multi-dimensional judgment in order to finally determine which implementation class to use, pull away if the following meta-programming with c#4.0 can actually implement the runtime configuration logic strategy, but it is not very mature at present, we have to implement all the business logic, and then based on the business needs of the background configuration;

For example, the system's background management automatically detects whether it is a rest day, if it is a rest day, then for "Employee" there is no right to perform "parentmessage" processing, is it very simple? Of course, a lot of good design can be moved to the system slowly, the premise is "specific areas of reconstruction-specific domain framework design", this degree of good grasp;

5 "DDD Simple Summary (what is DDD?) It's "tactical")

Recently discussed in the garden. NET technology worth worthless article is very fire, in fact, whether it is. NET or \java are tools, combat tools, must have a certain strategic design in order to let them play a specific role, can be likened to the art of the military, DDD. NET is just a war tool, Java is the same, Python, Ruby and so on, the key is design ideas, strategies; so we have long-term training is the design ability, appropriate familiarity with a certain technology platform, status quo; Java in the good, do not understand the enterprise structure is garbage,. NET again good, do not understand the design pattern like play does not turn;

All technical frameworks have their pros and cons, we only have to design, plan, and then use the appropriate technology in the appropriate location, the technology is good at this aspect, then put it in this position;. NET advantage in the development of speed, UI, then used for the development of the foreground part Java may have advantages in big data, distributed backend, then used for server development, search engine, Ruby is a dynamic language, can be used to achieve complex business dynamic configuration, set the director of the family to complete a large-scale campaign, no one who left who can not turn, no one more important than who, In a battle even army are not less, Yang door in the young men of the wind who look down on it, only the adviser can not be confused;

Sample demo code (domain model): Http://files.cnblogs.com/wangiqngpei557/Domain.DomainModel.zip

. NET domain driven design-see how DDD uses design patterns to subvert traditional architectures