. Net domain-driven design-first taste (2: Questions, patterns, principles, tools, processes, frameworks, and practices)

Reading directory:

• 1. 3. Principles
• 1.3.1. Simplified Aggregation
• 1.3.4. Separating use cases and interface functions (applicable to the design model)
• . Tools, frameworks, and components
• 1. 5. Process

1.3 Principle

The principle is crucial for any technical implementation. When designing a system function, we pay attention to the design principle:

【Single Responsibility Principle single responsibility principle, liesskey replacement principle liskov substitution principle, dependency inversion principle dependence inversion principle, interface segregation principle, Demeter law of Demeter, open and close principle open close Principle].

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

[Stratified principle to avoid circular dependency ].

Not only do we have to pay attention to principles when doing things in the technical field, but those who violate the principles will be heartless punishments.

For the design of DDD, we also need to observe the corresponding principles. Of course, if we do not observe it in the early stage, there will be no difference, but the problems will be exposed in the development stage.

Let's look at two basic design principles.

[Simplified aggregation]

The design principle of streamlining aggregation is undoubtedly the most important. Some Software Engineering Methodology books often guide us in UML business modeling,"No technical implementation issues need to be considered at this stage"According to this guiding principle, I designed the UML and successfully created the ER relationship diagram. As a result, I found that such a database structure cannot be used as the final project development database. What's wrong? I repeatedly searched the guidance books and then found a sentence like this on the professional DDD book:

• ["Design without technical implementation is always on paper "].

I think this sentence really describes the gap between methodology and enterprise applications. Many technical ideas or theories are really good, but to use them, we need to solve many problems. Ddd cannot avoid this problem. How can we avoid the problem of excessive design when designing a UML model? Here, we only need to abide by the [Simplified aggregation] principle and won't lead to excessive design problems.

In the previous example, we designed a complete UML domain model, but we didn't [streamline aggregation] And refactor it. So the problem with it is that it cannot be used for project development.

1.1

The initial version of the domain model we have built should be like this. There is a strong relationship between the entity and the entity, and the association between the aggregation is too large, resulting in a pull. If you follow this link to create a database, there must be a lot of primary/Foreign keys between databases, affecting the database design. If such a relationship is used in a program, there will also be many problems, and we cannot use a few aggregates, when we use a certain aggregation, it will drag out the associated aggregation one after another, not only does the query impede the creation of aggregation in the factory, but also cannot be constructed during the creation of aggregation. No matter what operations are performed on the aggregation repository, the program logic will be affected, therefore, we need to split a complicated and huge relationship.

Disconnect all parts of the red line and associate the aggregation with IDs. This will become clearer. Because few programs require the participation of all business models on a certain business logic point, this facilitates program development and database design, making it easier for ORM to use. The delay loading of ORM is actually to aggregate dependencies. You can query the desired model as needed. However, even though the program can be said in the past, the design of the database cannot be said. For different ORM frameworks, the ing principle is different and requires slight adjustment when constructing the model. For example, in entityframework, the ing scheme supported by the ing scheme ensures that your model can be smoothly mapped. Here, we will not talk about a detailed project for comprehensive practice. Then we will analyze the specific problems. [Wang qingpei has all rights reserved. For more information, please sign it.]

Finally, let's take a look at the decomposed class diagram:

1.2

In this way, the relevant core domain models can be used directly, without worrying about the problem of slow loading of the orm framework.

[Separation of Use Cases and functional interfaces (where the design mode is used )]

The separation of Use Cases and functional interfaces is actually an occupational disease that some people who are new to DDD are familiar with, because we are all familiar with object-oriented design. During UML modeling, we like abstraction very much and will clearly represent generalized relationships with inheritance, such as [user type ], different users have different behavior permissions. During preliminary design, we usually establish an inheritance relationship about users to express generalized business models. However, in the encoding stage, we will find that the obvious problem is that we include the repository behavior in the user aggregation of the launch case, which may be a bit abstract. We still use examples for analysis;

1.3

In, I separated the [admin] and [distribution] use cases. To express this, I cannot put the delivery behavior in [admin. When we model relevant permissions, we often subconsciously place their respective behaviors in their respective roles, if multiple roles share behavior in the later stage, it will be written in the abstract class and passed down using the virtual method. The problem lies in the role behavior. We know that if there is a behavior, it is possible to execute the irepository operation related to other aggregation operations in this behavior. In this way, the domain model will be messy, vertical analysis fails.

1.4

Ddd focuses on the field drive. In our opinion, [dispatching] and [checkorders] All inherit the administrator role, and the Administrator belongs to the background administrator, which means employees of the enterprise. Consumers are managers. Similarly, consumers may have the same situation. There may be many types of consumers, including VIP series (VIP1 \ VIP2 \ vip3 ...), There are diamond members. If this design is done, it cannot be said to be wrong. This is completely in line with the ideological requirements of DDD, but it is not ideal in actual situations.

Here we use our long-term design model. We can separate users from behavior through many medium models in the design model, then, the rules and conditions used are abstracted to completely independent users. When users use the rules, there is no direct attribution of behavior, but in fact they do have behavior.

1.5

In professional DDD terminology"Protocol mode"Service Rules can be extracted for objectization, and even configured at the end. What excites us most is that our painstaking design model can finally be used in a large area in system design. Isn't it a big surprise!

1.4 tools, frameworks, and components

Any architecture needs the support of frameworks and tools to become perfect.

When we develop in a certain architecture, we must support a lot of tools and frameworks to make the development work more convenient. This is also the same as the idea of [agile development. In the traditional three-tier architecture, we all need"Object ing", "AOP \ IOC"And so on. In DDD, we also need a lot of tools and frameworks that have not yet appeared. currently, only the entityframework framework on the net platform has done a lot of work for DDD. If our domain model cannot be mapped to the database, the cost of domain model development will be very high.

In the design phase, we lack a modeling tool for specific fields. Unlike UML, UML is too technical and universal. Ddd often mentions 【Field ExpertHe is the most authoritative leader in the field. The UML we created may not be understandable. After the technicians are technical, the formation of UML has actually changed ,【Field Expert] Is an uncertain guarantee. If we can language domain models, this will be a major achievement. [Field expert] He is familiar with everything, characters, and links in the field, but he cannot express his ideas clearly. If he can have a tool to assist his design, this tool can convert the designed model into a code model or a database model smoothly and equivalent. If this gap can be crossed, it will have a great influence on the industry.

1.8

If we can equivalent the technology of the real model, then everyone will really like requirement analysis, analysis and design.

Since it is a model-driven design, when we analyze such a system for users, the premise is that we have abstracted and encapsulated all the details in it, and each process can be split, finally, it can be combined to form an overall business model. Of course, this is only a technical outlook, and it is also our goal and goal.

We recommend the latest Martin Fowler book: domain-specific language

1.5 Process

Ddd is not a pure technical implementation, but a complete set of development ideas that run through all the lifecycles of software development. From the fields of our development and contact, we deeply digest our domain knowledge, which are all emphasized by DDD. In our daily development process, how should we deal with these processes? The requirement will not be as messy as before, but a rough sketch of a wide range of Domain Models. Such a requirement is an improvement for the team, department, and company. It is difficult to achieve a complete DDD process.

Most of us are working in non-professional R & D companies. The leaders hope to see things as soon as possible, good things are needed, but they do not follow good things. If you are lucky enough to have a R & D team for DDD, agile, and XP, You can regard the project as a lifelong work of art. [Wang qingpei has all rights reserved. For more information, please sign it.]

These two articles are my thoughts on DDD and I will share them with you.

In the next article, we will share with you the detailed use of a small system with a DDD architecture as a case.Analysis and Modeling, use of design patterns, database ing, and use of entityframeworkAnd can be used as the basis for real project development.