How can I persuade leaders to use DDD to construct the liver project?

author ： Little brother Fu
Blog ：https://bugstack.cn
original text ：https://mp.weixin.qq.com/s/ezd-6xkRiNfPH1lGwhLd8Q

precipitation 、 Share 、 grow up , Let yourself and others have something to gain ！

One 、 Preface

Leader ： Why use DDD？

I also think hard , How to tell the leader that we started from MVC Upgrade to DDD Well , because DDD The code structure is clearer 、 Domain driven development is more advanced than test driven development 、 The R & D brothers also want to use the new framework .

But such a chat was sprayed without saying , I have to say that you are over designing and fooling around , Editor's Note it ？ Because I didn't get to the point , you MVC upgrade DDD; What brings to the business 、 Improve delivery efficiency 、 Reduce the company's R & D costs , None ？ Not only is there no , You also said that for later iteration maintenance , More design and development time will be required in the early stage . Why? ？ You want this one Q Just send me away , I just came to our department KPI Hanging there , It makes my hair white ！ Don't fool around , Seeking stability ！

Then don't do it ？ WOW , Don't let them change their leaders ！ But before you do it , Think about it ,DDD No Silver Bullet, It's good that you have a cavity of warm blood , But you have to know DDD What are the design principles of 、 What is the more suitable scene 、 And MVC What's the difference between comparison .

Two 、 Development costs

Use DDD What is the cost of developing code with patterns ？ Because of the use of DDD Four layer layered structure Just like MVC Three layered structure Is it a waste of time ？ It's not , Because the four story structure is relative to the three-story structure , Instead, it better distinguishes the responsibilities of the code , After being familiar with the functional responsibilities of the module , Development will also be smoother .

Then here DDD What is the cost of Domain Driven Design and development ？ The cost is for a Complex systems have not yet In the early stage of development, I have enough experience to Split responsibility boundaries 、 Divide functional areas 、 Clarify the logic of the arrangement and Control of unknown process extension , Brought about by the Storm model design cost .

And commonly used MVC Structure basically won't have such a problem , Because in actual code ,DAO、PO、VO And so on are shared , When you are developing code , image Pile mud balls equally Write process oriented code , Directly connect the products in series PRD Function node , Don't think too much about decoupling and cohesion .

Isn't it possible to design patterns , This depends on which dimension you are standing in to think about the problem . Design patterns here are tactical issues ,DDD and MVC Is to identify strategic issues , It's kind of like saying ：“ The direction is wrong , Efforts are in vain ”

Now let's look at this development cost curve ：

• Compared with the other two layered structures , Use DDD When , We need to invest more time and cost in the early stage to design domain modeling , So the upfront cost will be higher .
• But as the business continues to iterate, the complexity of the logic increases ,DDD The code developed by the system architecture will be more stable , Also explains DDD Easier to expand and maintain .
• So the replacement of frame structure , Not where the development cost will eventually increase , If you don't do more modeling, you don't think about the field , So even if it's DDD Four tier architecture of , It also allows you to write MVC The effect of . And those architects or R & D personnel who are experienced in business scenarios , The responsibility boundary of each business function has been clearly defined , What core domain services need to be completed to realize a system requirement , In this case, use DDD It will not bring much development cost , On the contrary, it is more comfortable ！ That's why , Need domain experts , Because experts have accumulated a lot of experience in strategic design
• In addition, use DDD Domain driven design pattern , In addition to the iterative cost of solving requirements , More often, we have to face the adjustment of the company's strategy , System handover 、 Replacement and addition of personnel , We should continue iterative development under the original engineering architecture , Otherwise, it will be overturned and redone , In that case, the replacement cost will be greater , At the same time, it also develops an engineering code that is bound with personnel and is not easy to hand over and maintain .

3、 ... and 、 Architecture contrast

In understanding and mastering DDD On the way of Domain Driven Design , You are bound to encounter two abstract nails —— “ Anemia model ”、“ Congestion model ”：

• Anemia model ： Transaction script mode , It originated from EJB2, To Spring Enter open “ In the spring ” The golden age .
• Congestion model ： Domain model pattern ,2003 in , Until 《 Implement domain-driven design 》 The advent of , Just opened DDD Gate . But domestic micro Services 、 The rise of low code , Began to DDD heat

1. MVC

MVC The hierarchy will ：“ state ”( data , member object )、“ Behavior “( Logic 、 The process ), Separate into different objects , Only state objects (VO -> Value Object) It's called the anemia model , Only the object of behavior , This is common in framework layering Logic/Service/Manager layer ( Corresponding to EJB2 Medium Stateless Session Bean)

• To apply layers Service Use DAO、PO Development mode of infrastructure packaging business logic , At first glance, it seems that the application layer is the implementation of domain modeling ,” Domain layer “ With rich object Links , It is also very similar to the real domain model , But when our code is gradually implemented with the business function logic, we will slowly find , We wrote a pile of get/set object , And they are cross used repeatedly , No aggregation with any domain , That is, there is no action , Just a bunch of anemia model objects .
• The design of this anti pattern , In fact, it is completely related to object-oriented The design is the opposite , Object-oriented design wants behavior and data binding together , In contrast, the anemia model is more like process oriented design .
• stay MVC Under the hierarchical structure , All actions are written to Service In the object , Eventually you will get a set of transaction process scripts , Thus, it perfectly avoids the benefits of domain model design ( Clear responsibility boundaries 、 Aggregated functional services 、 Clear object orientation ).

2. DDD

DDD The hierarchical structure of is also the essence of object-oriented programming ：” An object has behavior and data “, The domain layer includes ： object 、 Aggregate object 、 Warehousing and Service Realization .

• DDD The hierarchical structure pays more attention to Domain Implementation of domain layer , The interface is defined and arranged by a very thin application layer , The specific implementation is done by the domain layer .
• All business logic is divided into functional areas according to their respective responsibility boundaries , Each functional domain is a concrete implementation of the structure of the congestion model .
• After the final implementation of such code , Whether in iterations 、 maintain 、 Personnel turnover , Can find the corresponding code implementation according to the domain design documents for development .

Four 、 Design principles

First DDD The design of is divided into strategy and tactics ;

• Strategic design ： From a business perspective , Build a business domain model 、 Divide responsibility boundaries , Establish the boundary context of a common language . The domain model structure constructed by top-level strategic design , It is the focus of the later arrangement of the whole service , It defines the functional responsibility boundaries 、 polymerization 、 Object etc. , This will definitely the development and delivery quality of the later service tactical realization . Attach importance to strategy , To land a good tactic ！
• Tactical design ： From a technical point of view , Focus on the technical implementation of the domain model , Complete function development and delivery . The focus of domain design includes ： Entity 、 Aggregate object 、 The value object 、 Field service 、 Storage , There is also a very important Design patterns . Any more complex domain model implementation needs to consider the use of design patterns , Otherwise, even if the strategy is excellent , Tactics can also return MVC Go to .

In order to DDD In the process of domain driven design landing , We should rely on the design idea of Domain Driven Design , Building domain models through event storms , Reasonably divide the logical and physical boundaries of the domain , Establish domain object and service matrix and service architecture diagram , The definition corresponds to DDD The code structure model of layered architecture idea , Ensure consistency between business model and code model . Through the above design ideas 、 Methods and processes , Instruct the team to follow DDD The design idea completes the design and development of microservices .

1. Rejecting mud ball monomers 、 Refuse polluting functions and services 、 Refuse to add functions and schedule for one month
2. Build a highly available application service that is easy to meet the high-speed iteration of the Internet
3. Materialization 、 Assembly 、 Choreographable Services , Improve people's effectiveness
4. Domain Driven Design , Not data driven design , It's not interface driven design
5. We need to have a clear hierarchy of functions , Instead of putting everything in a big basket

DDD Domain model design for , Context within boundaries , Can be split into independent microservices . But not just from a business perspective , Also consider non business technical factors , Include ： High performance 、 Security 、 The team 、 Heterogeneous technology, etc , These non business technical factors , It will also determine the specific landing of the domain model .

5、 ... and 、 for instance

You say me MVC Not good. , You say me MVC Anemia model ,PO Expanding class , But let me use DDD It's all theory , Programmers prefer to see the code that has been implemented , Tell me how to do .

Why is it so difficult to land ？ Because from MVC Over to DDD Describe and compare Just accumulated MVC The lesson of failure , But there is no DDD Successful experience , So I want to land more often DDD In addition to theoretical support , We need a case in front of us .

1. Engineering structure

So in order for more farmers to see in DDD The last road you can take , A special toss DDD Distributed lottery system , To tell you how to use DDD Develop business requirements ;

The overall system architecture design includes 6 A project ：

1. Lottery： Distributed lottery service system , Provide lottery business field functions , Distributed deployment RPC service .
2. Lottery-API： gateway API service , Provide ;H5 Page lottery 、 Official account development award reply .
3. Lottery-Front：C End user system ,vue H5 lucky-canvas Big turntable lottery interface , Explain vue Engineering creation 、 Introduce modules 、 Development interface 、 Cross domain access and function realization
4. Lottery-ERP：B End operation system , Meet the query of operators for activities 、 To configure 、 modify 、 Audit and other operations .
5. DB-Router： Sub database and sub table routing component , Develop a system based on HashMap Core design principles , Use hash + The way of perturbation function , Components that hash data into multiple library tables , And verify the use of .
6. Lottery-Test： Test and verify the system , For test verification RPC service 、 Test system for system function call .

2. Process disassembly

When we get the product RPD in the future , It's not direct development , Instead, we need to disassemble a domain service of object-oriented design from the process , give an example ;

• Disassembly function flow , Refining domain services , Teach you step by step how to disassemble a business function process into domain modules under each responsibility boundary , By connecting the developed domain services in the application layer , Provide the whole service link .
• Through such design and landing ideas , As well as in the process of the function according to the object-oriented idea, using the design pattern to design , Make every step of the code clear and easy to understand , In this way, the implemented code is easier to maintain and expand .
• therefore , You learn more than just code development in the process , There are more landing ideas and practices reflected in this . You can also develop such a project for you in the future or during the interview , Design ideas for some practical complex scene problems , Lay a good foundation .

3. Practice together

If you are right about DDD Practical learning and emotional interest , You can also join DDD Distributed lottery system Practice , To absorb a landing experience .PS： Spend some money on yourself , Make valuable investments , Just buy less skin

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

• Have Java R & D personnel of programming foundation , Want to improve their technical ability
• Hope to improve coding thinking , Remove the bad smell from the code
• Willing to be an architect , But it is still in a certain bottleneck period
• Want to join a big factory as a yard farmer , But I always feel like I can't find a way

6、 ... and 、 summary

• DDD Not at all Silver Bullet, You can't expect to change the framework , Can change the shit mountain of development code , The problem of bad taste .MVC The same structure can develop good code , It's just less stable , It is not conducive to long-term maintenance and iteration .
• DDD The complexity is due to the lack of experience in domain modeling , If you already have the same need MVC The middle ho ho absorbs enough boundary context summary , Now change DDD It allows you to develop code faster .
• DDD Not all engineering models are complex ,DDD It's the guiding ideology , You can DDD Because of the introduction of RPC Disassemble the layers of each module , It is also possible not to introduce... When the business scale is medium or complex RPC frame , In this way DDD Will be shorter and more capable , And MVC Compared with just defining interfaces in the domain layer , Put the code in domain Layer implementation , Put the data into the storage layer for processing . Reference code ：https://github.com/fuzhengwei/CodeGuide