Foreword: In a project, we have a new technical manager. When he first came into contact with the project, he found that our framework uses the traditional MVC model (this model has been used for development), so our project infrastructure It has been rebuilt and introduced the idea of DDD domain-driven design.
1. What is DDD domain-driven design thinking
At the beginning, the manager asked me if I knew about DDD domain-driven design. At that time, I was so confused that I had never heard of it. This design idea.
Domain-Driven Design : DDD for short is an object-oriented modeling method for comprehensive software system analysis and design. Software development ideas.
1.1 What is Domain
I think we need to know what kind of system we are going to do now, and what kind of problems this system solves. Any system will have its own specific field. For example, a forum is a field. If you want to build a forum, its core business is determined, such as core basic functions such as user posting and replying. For example, an OA office system, which belongs to the office system, requires workflow, user management and other core links. Therefore, systems in the same field have the same core business, so the nature of the problems they solve is similar.
Therefore, we can infer that a domain can be understood as a problem domain in essence, as long as it is the same domain, the problem domain is the same. Therefore, as long as we determine the field to which the system belongs, then the core business of the system, that is, the key problems to be solved, and the scope boundary of the problem are basically determined. Usually we say that to become an expert in a field, one must study in this field for many years. Because only if you have studied for many years, you will encounter a lot of problems in this field, and your experience in solving problems in this field is also very rich. In many cases, domain experts are more popular than technical experts, such as experts in the financial field.
1.2 What is Design?
The design in DDD mainly refers to the design of the domain model. Why domain model design instead of architectural design or other design? Because DDD is a software development idea based on model-driven development, it emphasizes that the domain model is the core of the entire system, and the domain model is also the core value of the entire system. Each domain has a corresponding domain model, which can help us solve complex business problems very well.
From the perspective of domain and code implementation, the domain model binds the domain and code implementation, ensuring that the final code implementation must solve the core problems in the domain. Because: 1) domain-driven domain model design; 2) domain model-driven code implementation. As long as we ensure that the design of the domain model is correct, we can be sure that the domain model can solve the core problems in the domain; in the same way, as long as we ensure that the code implementation is implemented in strict accordance with the intention of the domain model, we can guarantee the final result Code that solves the core problems of the domain. This idea is in stark contrast to the traditional software development methodology in which the stages of analysis, design, and coding are separated (and the products of each stage are also different).
1.3 What is a driver (Driven)
What is a driver, a driver is:
- Domain-driven domain model design.
- The domain model drives the code implementation. This is in contrast to our traditional database-driven development ideas. In DDD, we always take the domain as the boundary, analyze the core issues (core concerns) in the domain, then design the corresponding domain model, and then drive the code implementation through the domain model. And things like database design, persistence technology, etc. are not the core of DDD, but peripheral things.
1.4 Summary
- A domain is a problem domain, with boundaries, and there are many problems in the domain.
- The big problem to be solved by any system corresponds to a field.
- Solve the core problems in the field by establishing a domain model, model-driven thinking.
- The goal of domain modeling is for the issues we care about in the domain, that is, only for the core concerns, not for all the issues in the entire domain.
- When designing a domain model, a certain degree of abstraction, versatility, and reuse value should be considered.
- Drive the implementation of the code through the domain model to ensure that the code makes the domain model land, and the code can finally solve the problem.
- The domain model is the core of the system and the direct precipitation of business in the domain, which has great business value.
- Technical architecture design or data storage are on the periphery of the domain model, helping the domain model to be implemented.
2. Why DDD is difficult to implement
- After searching on the Internet, there are not many documents and practical cases about DDD in China, except for a few well-known large factories, it is rare to see the practice of DDD. Too few best practices mean that we have fewer materials to refer to, and the risk of project failure is greater.
- There are many concepts and terms in DDD, such as aggregate root, value object, hexagonal architecture, CQRS (command and query responsibility separation), event-driven and other concepts. When many people see so many concepts, they start to retreat in their hearts.
- DDD requires us to spend a lot of time and energy on domain modeling, and it may also lead to a situation where the effort is not directly proportional to the benefit. Because the division of bounded contexts is a test of the architect's business level. If the business model is not well identified, the model may soon be corrupted in the iterative process.
- There is no standard: DDD is a set of ideas, a set of domain modeling design, a set of use in a specific context. So to implement DDD in 1,000 teams, there may be 1,000 different solutions. A person who has practiced DDD for many years, changes a company, changes a team, brings his original method over and implements it, which is generally not applicable.
Therefore, it is just a design idea. When someone in the team proposes and builds it, it is indeed more convenient for large teams to separate the core from the business, but it is impossible to expect DDD to solve all problems. Yes, programmers are very practical, and they will not do things that are not beneficial. You must be able to effectively help him improve before he will accept it. For example, when a team member asked, after we implement this method, do we not need to work overtime? Or can overtime hours be reduced?
So there is no good framework idea, only programmers who keep learning.