How can I convince my leaders to let me use DDD to build a liver project?

Author: Brother Xiaofu
Blog: https://bugstack.cn
Original: https://mp.weixin.qq.com/s/ezd-6xkRiNfPH1lGwhLd8Q

Precipitate, share, grow, and let yourself and others gain something! 😄

I. Introduction

Leadership: Why use DDD?

I also thought hard about how to tell the leader that we should upgrade from MVC to DDD, because DDD has a code structure, domain-driven development is more advanced than test-driven development, and the R&D brothers also want to use the new framework.

But if you don't talk about it for a while, you have to say that you are over-designing and messing around. What's going on? Because we missed the point, did you upgrade DDD from MVC; what bring to the business, improve delivery efficiency, and reduce the company's R&D costs, none? Not only no, you also said that for the later iterative maintenance, more design and development time will be required in the early stage. what? Do you want to send me away with this Q? I just came to our department and the KPI was hanging there, and my hair turned white! Don't fool around, stay safe!

Then don't do it? Wow, don't let the leaders change! But before you do it, you have to think clearly. DDD is not Silver Bullet. Although it is good to have a passion, you must also know what the design principles of DDD are, what scenarios it is more suitable for, and what is the difference between it and MVC.

2. Development cost

What is the cost of developing code using the DDD pattern? Is it because using the DDD four-tier hierarchy is more time-consuming than the MVC three-tier hierarchy? In fact, it is not, because the four-layer structure better distinguishes the responsibilities of the code compared with the three-layer structure, and the development will be smoother after being familiar with the function and responsibilities of the module.

So where is the cost of DDD domain-driven design development here? This cost lies in the fact that for a complex system and not yet sufficient experience in the early stage of responsibility boundaries, divides functional areas, clearly arranges logic, and the expansion of unknown processes. The storm model is designed to cost .

However, the commonly used MVC structure basically does not have such a problem, because in the actual code, DAO, PO, VO, etc. are all shared. When you develop code, you write -oriented code like piles of mud balls. , you can directly connect the PRD function nodes of the product in series, without thinking too much about decoupling and cohesion.

Isn't it possible to design patterns? It depends on which dimension you are thinking about. Design patterns are a tactical problem here, DDD and MVC are a strategic problem, a bit like saying: "The direction is wrong, and efforts are in vain"

So now let's look at this development cost curve:

• Compared with the other two hierarchical structures, when using DDD, it is necessary to invest more time and cost to design domain modeling in the early stage, so the up-front cost will be higher.
• However, as the complexity of the logic after the continuous iteration of the business increases, the stability of the code developed by the DDD system architecture will be better, which means that the DDD is easier to expand and maintain.
• Therefore, the replacement of the framework structure is not the place that ultimately increases the development cost. If you do not do domain modeling and do not do more design thinking, then even the four-tier architecture of DDD can allow you to write the effect of MVC. Those architects or R&D personnel who are experienced in business scenarios have already clearly defined the responsibility boundaries of each business function, and what core domain services need to be completed to achieve a system requirement. In such a situation, using DDD will not bring much development. The cost, on the contrary, is more convenient! This is why it is said that domain experts are needed, because experts have accumulated a lot of experience in strategic design
• In addition, using the DDD domain-driven design model for development, in addition to solving the iterative cost of requirements, more often it is necessary to face the company's strategic adjustment, the handover of the system, the replacement and addition of personnel, all under the original engineering structure. Continue iterative development, otherwise it will be overturned and re-made, and the replacement cost will be greater, and at the same time, an engineering code that is bound to personnel and is not easy to be handed over and maintained is developed.

3. Architecture comparison

On the way to understand and master DDD domain-driven design, you will definitely encounter two abstract nails - "anemia model" and "congestion model":

• Anemia model : transaction script mode, which originated from EJB2, and entered the prosperous age of "spring" in Spring.
• congestion model : Domain model model, proposed in 2003, until the advent of "Achieving Domain-Driven Design", the door to DDD was opened. But in China, it was not until the rise of microservices and low-code that DDD became hot

1. MVC

MVC hierarchical structure will: "state" (data, member objects), "behavior" (logic, process), separated into different objects, only the state of the object (VO -> Value Object) is called an anemic model, only The object of behavior is the common Logic/Service/Manager layer in the framework layering (corresponding to the Stateless Session Bean in EJB2)

• The development method of using DAO and PO infrastructure to wrap business logic in the application layer service. At first glance, the application layer is the realization of domain modeling. The "domain layer" has rich object links, which is very similar to the real domain model. , but when our code is gradually implemented with the business function logic, we will gradually find that we have written a bunch of get/set objects, and they are used repeatedly and cross-purposely, without being aggregated with any field, that is, without any behaviors, Just a bunch of anemic model objects.
• The design of this anti-pattern is actually completely contrary to the object-oriented design of . Object-oriented design prefers to bind behavior and data together. The contrasting anemia model is more like process-oriented design.
• Under the MVC hierarchical structure, all behaviors are written into the Service object, and you will end up with a set of transactional process scripts, which perfectly avoids the benefits of domain model design (clear responsibility boundaries) , aggregated functional services, clear object orientation).

2. DDD

The hierarchical structure of DDD is also the essence of object-oriented programming: "an object has behavior and data", which includes: object, aggregate object, repository and service implementation at the domain layer.

• The layered structure of DDD pays more attention to the realization of the Domain layer. The thin application layer defines the interface and the orchestration interface, and the domain layer does the specific implementation.
• All business logic is divided into functional areas according to their respective responsibility boundaries, and each functional area is a concrete realization of the structure of the congestion model.
• Then, after such code is finally implemented, no matter in iteration, maintenance, or personnel replacement, it is easy to find the corresponding code implementation according to the domain design document for development.

4. Design principles

First, the design of DDD is divided into strategy and tactics;

• Strategic design: From a business perspective, establish a business domain model, divide responsibility boundaries, and establish a bounded context of a common language. The domain model structure constructed by the top-level strategic design is the focus of the post-service orchestration. It determines the functional responsibility boundaries, aggregations, objects, etc., which also determines the development and delivery quality of post-service tactics. attaches great importance to strategy, in order to implement good tactics!
• Tactical design: From a technical perspective, focus on the technical implementation of the domain model, complete functional development and delivery. The focus of domain design includes: entities, aggregate objects, value objects, domain services, warehousing, and a very focused design pattern. Any complex domain model implementation needs to consider the use of design patterns, otherwise even if the strategy is excellent, the tactics can go back to MVC.

In the process of implementing DDD domain-driven design, it is necessary to rely on the design idea of domain-driven design, establish a domain model through event storms, reasonably divide the domain logic and physical boundaries, establish domain objects, service matrices and service architecture diagrams, and define domain objects that conform to the DDD classification. The code structure model of the layer architecture idea ensures the consistency of the business model and the code model. Through the above design ideas, methods and processes, guide the team to complete the design and development of microservices according to the DDD design idea.

1. Reject mud ball small monomers, refuse to pollute functions and services, refuse to add functions and schedule for one month
2. Architect high-availability application services that can easily meet the high-speed iteration of the Internet
3. Materialized, assembled, and choreographed services to improve human efficiency
4. Domain-driven design, not data-driven design, not interface-driven design
5. It is necessary to have clear layers of functions, rather than putting everything in a basket

DDD's domain model design, context within bounds, can be split into independent microservices. However, it is not only necessary to look at the problem from a business perspective, but also to consider non-business technical factors, including: high performance, security, team, technology heterogeneity, etc. These non-business technical factors will also determine the specific implementation of the domain model.

5. Give an example

You say that my MVC is not good, you say that I have an anemic model of MVC, and the PO class is constantly expanding, but let me use DDD as a theory. Programmers prefer to look at the code that has already been implemented and tell me how to do it.

Why is it so hard to land? Because the transition from MVC to DDD description and comparison only accumulated lessons from the failure of MVC, but there is no successful experience of DDD, so more often, if you want to implement DDD, in addition to theoretical support, you need a case in front of you.

1. Engineering structure

Therefore, in order to let more coders see a way to go in DDD, we specially tossed a DDD distributed lottery system to tell everyone how to use DDD to develop business needs;

The overall system architecture design includes 6 projects:

1. Lottery: A distributed deployment lottery service system that provides lottery business domain functions and provides RPC services in a distributed deployment manner.
2. Lottery-API: Gateway API service, provided; H5 page lottery, public account development reply message lottery.
3. Lottery-Front: C-side user system, vue H5 lucky-canvas lottery interface, explaining vue project creation, introduction of modules, development interface, cross-domain access and function implementation
4. Lottery-ERP: B-side operation system, which satisfies the operation personnel's query, configuration, modification, audit and other operations for activities.
5. DB-Router: A sub-database sub-table routing component, developed a component based on the core design principle of HashMap, using the method of hashing + perturbation function, hashing data into multiple library tables, and verifying the use.
6. Lottery-Test: Test verification system, a test system used to test and verify RPC services and system function calls.

2. Process disassembly

When we get the RPD of the product, we do not start developing directly, but we need to disassemble a domain service of object-oriented design from the process, for example;

• Disassemble the functional process, refine the domain service, and teach you step by step how to disassemble a business functional process into domain modules under each responsibility boundary, and provide the entire service link by connecting the developed domain services in the application layer.
• Through such design and implementation ideas, as well as the use of design patterns to design process-oriented functions in accordance with object-oriented ideas, each step of the code becomes clear and easy to understand, so that the realized code is easier to maintain and expand. .
• Therefore, what you learn in this process is not only code development, but also more landing ideas and practices are reflected in it. It can also lay a good foundation for you to develop such a project in the future or to design ideas for some actual complex scene problems during the interview process.

3. Practice together

If you are interested in DDD practice learning, you can also join the practice of DDD distributed lottery system to absorb a practical experience. PS : Spend some money for yourself and make a valuable investment, just buy one less skin

Learning link: https://bugstack.cn/md/project/lottery/introduce/Lottery%E6%8A%BD%E5%A5%96%E7%B3%BB%E7%BB%9F.html

• R&D personnel with Java programming foundation and want to improve their technical ability
• Hope to improve coding thinking and remove bad smells from code
• Willing to become an architect, but still in a certain bottleneck period
• I want to join a big factory as a code farmer, but I always feel that I can't find a way

6. Summary

• DDD is not Silver Bullet, you can't expect to change the framework structure, you can change the development code like a mountain of shit⛰, which brings the problem of bad taste. The MVC structure can also develop good code, but its stability is worse, which is not conducive to long-term maintenance and iteration.
• The complexity of DDD is due to the lack of experience in domain modeling. If you have absorbed enough bounded context summaries in MVC for the same requirement, switching to DDD now allows you to develop code faster.
• Not all engineering model structures of DDD are complex. DDD is the guiding ideology. You can disassemble the layers of each module because of the introduction of RPC in the DDD four-layer architecture, or you can not introduce the RPC framework when the business scale is medium and complex. , such DDD will be shorter and leaner. Compared with MVC, it only defines interfaces in the domain layer, puts the code in the domain layer for implementation, and puts the data in the storage layer for processing. Reference code: https://github.com/fuzhengwei/CodeGuide