. NET domain driven design-first taste (principles, tools, processes, frameworks)

Read the catalogue:

• 1. Principles
• 1.1. Thin Aggregation
• 1.2. Separating use cases and interface functions (where design patterns are useful)
• 2. Tools, frames, components
• 3. Process

1 "principle

Principle is essential for any technology implementation, and when designing a system function we are concerned with design principles:

" single Responsibility Principle, Richter substitution principle Liskov Substitution Principle, dependency inversion principle dependence inversion Principle, The principle of interface isolation interface segregation Principle, Dimitri Law of Demeter, open Close Principle".

In architecture design, we also pay attention to architectural principles:

"Layering principle, avoiding cyclic dependence".

Not only in the technical field in a person to do things to pay attention to principles, contrary to the principle of waiting for you will be ruthless punishment.

For DDD Design We also have a corresponding principle to abide by, of course, if we do not observe the difference in the early stage, but to the development phase of the problem will be exposed.

Let's take a look at two basic design principle questions.

"Thin Aggregation"

The design principles of streamlined aggregation are undoubtedly the most important. Some software engineering methodology books often guide us in UML Business modeling,"There is no need to consider any technical implementation issues at this stage,"I followed the guiding principles of UML design and then smoothly create an ER diagram, It turns out that such a database structure simply cannot be used as the final project development database. Where's the problem? I have repeatedly queried the guide books and later in the professional DDD books to see a sentence about this:

• "The design that does not take the technology realization as the premise isthe paper".

I think this is a true description of the gap between methodology and enterprise applications, many technical ideas or theories are really good, but to use it needs to solve a lot of problems. DDD also avoids this problem, and how to avoid the problem of designing a UML model without causing excessive design, here we only need to adhere to the "thin aggregation" principle will not lead to excessive design problems.

In the previous example, we designed a complete UML domain model, but we did not do a "thin aggregation" refactoring, so it has the problem of not being able to develop the project.

1.1 Figure

The initial version of the domain model we built should be such that there is a strong link between entities and entities, and that the association between aggregations is too large to lead to reaching. If you create a database according to this relationship, then the main \ Foreign key between the database is sure to have a lot of impact on the design of the database. This kind of relationship if used in the program will also have a lot of problems, we can not do a few aggregation of use, when we use a certain aggregation, it will be a succession of the associated aggregations are dragged out, not only in the query when the obstruction and when the factory to create aggregations, there will be an inability to construct the problem, No matter what happens to the aggregation repository, it affects the logic of the program, so we need to split up a complex, huge relationship.

The part of the red line is all broken, and the aggregation is correlated by ID, so it becomes clear. Because very few programs in a business logic point on the need to participate in all the business model, it is convenient for the development of the program also facilitates the design of the database, more convenient use of ORM. An ORM's lazy loading is actually a way of aggregating dependencies that can be queried for the desired model when needed. However, although the procedure can be said in the past, then the design of the database is not justified. For different ORM framework mapping principle is different, in the construction of the model when the need for a slight adjustment, such as in EntityFramework, it can support the mapping scheme you ensure that your model can smoothly map the past, here is not torn behind there is a detailed project to do comprehensive practice, At that time, specific analysis of specific problems.

Finally, let's look at the exploded class diagram:

1.2 Figure

This makes it clear that you can use the relevant core domain model directly, and you do not need to worry about the delay loading of the ORM framework.

"Separating use cases and functional interfaces (where design patterns are used)"

Separating use cases and functional interfaces is also an occupational disease that a friend of the first contact with DDD can commit because we are all familiar with object-oriented design. In the UML modeling we all like abstract, will be very clear with the generalization of the relationship with inheritance to express, such as "user type", different users have different behavior permissions, in the initial design we will generally establish a user's inheritance relationship to express the generalization of the business model. But the obvious problem in the coding phase is that we include the behavior of repository on the user aggregation of the initiating use case, which may be a bit abstract. We still use examples to analyze;

1.3 Figure

I separated the "admin" and "distribution" use cases, and wanted to express that it was not possible to put the delivery behavior in "admin". When we model the relevant permissions, we often subconsciously put their actions in their respective roles, if the later existence of multi-role sharing behavior will be written in the abstract class using virtual method to pass down. The problem is that in the role behavior, we know that if there is a behavior then it is possible to perform irepository operations on other aggregations in the behavior, which will make the domain model messy and cannot be analyzed vertically.

1.4 Figure

DDD is a field-driven, in our opinion, "dispatching", "checkorders" are inherited administrator roles, administrators belong to the background management, meaning the employees of the enterprise. For consumers, they are managers. Similarly, consumers will also have the same situation, there may be many types of consumers, there are VIP series (VIP1\VIP2\VIP3 ...), there are diamond members and so on. If this design is not wrong to say, this is fully in line with the thought of DDD, but the reality is not ideal.

Here is the use of our long-term design pattern, we can through the design patterns in many of the patterns to separate the user from the behavior, and then the use of the rule conditions abstracted out completely independent of the user, users in the use of the time there is no direct behavior attribution, but in fact they do have behavior.

1.5 Figure

In the professional DDD terminology, the "protocol model"is used to extract the business rules into objects, and even finally, the rules can be configured. What excites us most is that the design pattern of our painstaking learning can finally be used in large area in system design, is not a very surprising thing!

2 "tools, frames, components

Any kind of architecture requires a framework, tools, and support to become perfect.

When we develop under some kind of architecture, we have to need a lot of tools and frameworks to make the development work easier, which is the same as the idea of "agile development". In the traditional three-tier architecture we all need a similar auxiliary framework for "Object mapping", "AOP\IOC" , and so on, in order to make the possibility of the architecture ahead. In DDD We also need a lot of tools, frameworks that are not yet present, and in the. NET platform only the EntityFramework framework is doing a lot of work for DDD, and if our domain model doesn't map to the database, Then the cost of domain model development will be great.

In the design phase, we lack a specific domain-oriented modeling tool, unlike UML, UML is too technical generalization. DDD often bring up the " domain expert " Corner, he is the most authoritative field leader, we created the UML they may not be able to understand, through technical personnel after the formation of UML has actually been stale, " Domain experts " is to understand the non-understanding can not be sure of the guarantee. If the domain model can be linguistically, then this will be a big achievement. "Domain experts" are familiar with anything, people, and links in the field, but he cannot express his ideas, and if he can have a tool to assist his design, the tool can transform the design model into a code model or a database model by smoothing the equivalent technology. This gap would have a big impact on the industry if it could be crossed.

1.8 Figure

If we can be equivalent to the real model in the technical, then really everyone will like the demand analysis, analysis and design.

Since it is a model-driven design, we are analyzing a system like this for the user, provided that we have an abstract encapsulation of all the details inside, each of which can be split and then merged together to form a whole business model. Of course, this is only a technical outlook, but also our goal of struggle and ideals.

Recommend a book from the latest Martin Fowler: "Domain-specific language"

3 "Process

DDD is not a purely technical implementation, but a set of development ideas that run through all the lifecycle of software development. From our development of contact areas, the field of knowledge in-depth digestion, these are the emphasis of DDD. So how do we deal with these processes in our daily development process, where the need is no longer a messy draft, but a rich domain model sketch. Such requirements for the team to the Department and even for the company is an upgrade, to achieve complete DDD process is actually difficult.

How the company leaders look at this way of development, most of us are in some non-professional research and development companies work, the leadership wants to see things as early as possible, it is very contradictory, need good things but not according to good things to do. If you are fortunate enough to have a research and development team for DDD, agile and XP, then you can treat the project as a lifelong artwork.

These two articles are mainly some of my feelings about DDD, share to everyone.

The following article will be detailed using a DDD architecture of small system as a case to share, which will include the analysis from the requirements of modeling, design patterns of use, database mapping, the use of EntityFramework and so on, can be used as a basis for real project development.

. NET domain driven design-first taste (principles, tools, processes, frameworks)