Is Domain Driven Design (DDD) reliable?

hello, Hello everyone , I'm Zhang Zhang ,「 The road to the advanced architecture 」 The public name author .

It seems that in recent years DDD Special fire , About DDD Is it a silver bullet or garbage There are still a lot of analysis on the Internet .

Recently, a classmate in the group was infatuated with Domain Driven Design （DDD）, The reason is to spend money on geeks to learn DDD Curriculum , Then I want to practice it in the work project , Let the theory fall to the ground

DDD Layered architecture

I believe most people know DDD The developer of the , The supporting view is mainly that ：

DDD（Domain Driven Design, Domain-driven design ） As a software development method , It can help us design high quality software models . With the right implementation , We go through DDD The finished design is exactly how the software works .

The key of business system design is how to define the model of the system and the relationship between the models , The main part is the definition of domain model , When we determine the model , The relationship between models will also be clear .

Eric Evans stay 《 Domain-driven design － How to deal with the complexity of software core 》 This book proposes a traditional four tier architecture model .

A brief summary is understood as follows ：

• The interface layer Interface： Mainly responsible for interacting with external systems & signal communication , For example, some dubbo service 、Restful API、RMI etc. , This layer mainly includes Facade、DTO Some more Assembler;

• application layer Application： The main component of this layer is Service service , But pay special attention to , This layer Service It's not simple DAO Layer packaging , In the framework of Domain Driven Design ,Service The first floor is just one floor “ thin ” A layer of , It doesn't implement any logic inside , Just responsible for coordinating and forwarding 、 Delegate business actions to the lower domain layer ;

• Domain layer Domain：Domain Layer is the core of domain model system , Responsible for maintaining object-oriented domain model , Almost all business logic will be implemented in this layer . The interior mainly includes Entity（ Entity ）、ValueObject（ The value object ）、Domain Event（ Field events ） and Repository（ Storage ） And many other important domain components ;

• Infrastructure layer Infrastructure： It is mainly Interfaces、Application and Domain Three layers provide support . All related to specific platforms 、 Framework related implementations will be implemented in Infrastructure Provided in the , Avoid three layers, especially Domain Layer doping into these implementations , thus “ Pollution ” Domain model .Infrastructure One of the most common facilities in is the concrete implementation of object persistence .

Anemia model vs Congestion model

Q1： So-called “ Anemia model ” What is it ？

In traditional MVC Under layered architecture , We divide the project structure into Controller,Service,DAO These three main layers , All the business logic is Service In the embodiment , And our entity class Entity But it just acts as an interface with the database ORM Mapped data containers , It does not reflect the business value of the model .

Q2：“ Anemia model ” What's the harm ？

In our code Will see all kinds of setter Methods and various parameter verification codes , Especially in Service layer , But these codes do not reflect its business value .DDD It is recommended that you write code in congestion mode , That is to say OOP The way to do abstract , Then hang the behavior on the object , Not in a pure process A way to write code .

Q3： What is the so-called congestion ？

Is that the object itself has many associated behaviors , Instead of just a simple database table field mapping .

DDD The claimed advantage of the congestive model is , Most of the behavior is encapsulated inside the object , So when we read the process code , It is clear at a glance , Can see directly step 1,step 2,step 3. But in reality, even if we don't have to OOP To organize behavior , The same can put different businesses step Package and reuse well .

The service granularity of some companies is particularly detailed , Such as the only 5000-10000 Line code , stay DDD The advantage of the congestion pattern claimed in is not so obvious .

It is convenient to guide the division of micro services ？

I believe many friends know “ DDD It can effectively guide the splitting of micro services ”, On this point , Mainly to make use of Bounded context （Bounded Context）.

The bounding context is DDD Elements used to divide different business boundaries in , The meaning of business boundary here is 「 Solve different business problems 」 The problem domain and the corresponding solution domain . You can think that the bounded context exists to solve some type of business problem .

How to divide it ？

It is mainly the abstraction of data and function . for example ： Take-out food 、 Property 、ERP Common data models for these products , User resources can be split into one service , It's very simple, isn't it ？ But this is the first step in the long march , The difficulty lies in the specific coding practice DDD Application .

Many people have come to the conclusion that ：DDD It is helpful for service division , However, the requirements for personnel ability are very high .

The architecture evolution of any software is a spiral .

• When you don't have enough experience to solve the problem directly , Or when the problem is too large to be solved with experience , The only way to support your decision-making is to analyze the input problem effectively .

• Use DDD Guide the division of micro services , It can make up for the lack of experience to a certain extent , Make a reasonable system architecture design .

Let's summarize

The focus of domain driven development is the domain model , All considerations should be from a domain perspective , Focus on business . The domain model must be able to accurately express the business logic , The domain model needs to be continuously improved in the development process , And can guide the development work of Engineers .

however , Reality is often not what we expected ：

• About DDD There are still too few best practices .

Apart from several well-known large factories, we seldom see anything about DDD The implementation practice of , Too few best practices mean , There are few materials we can refer to , The risk of project failure is high .

• DDD There are many new concepts and terms in

such as Aggregate root , The value object , Hexagon structure ,CQRS( Separation of command and query responsibilities ), Event driven and so on . When many people see so many concepts , The heart began to retreat .

If you are a programmer who has worked in the front line of a large company for two or three years , These new concepts 、 The essential content of nouns , In fact, it should be well understood . There's nothing worth saying . If it's to go out and share Show once , You can learn from the packaging , Don't make yourself look so earthy , Ha ha ha ~

• About ROI Need further discussion

DDD We need to spend a lot of time and effort in domain modeling , And it may also lead to the situation that the payment is not proportional to the income . Because the division of boundaries and contexts is a great test of the business level of architects . If there is no business model, it will be well identified , Then the model may soon corrupt in the process of iteration .

Today I mainly talked with you DDD The main concept and service division of the company are very simple, and the selling points are respected . In fact, we should put DDD Used in specific code , It also requires the ability of developers to be very high , Not only do you have to know the things in the eight part essay , Also have high requirements for coding skills .

And finally ： Better believe than have no book , Practice is the only criterion for testing truth ！  

  welfare ： Pay attention to the official account reply key ：DDD, Free access to   full set DDD Related sharing materials

·················· END ··················

Official account , Free learning materials

Ten years of R & D , Big factory architect ,CSDN Blogger

Focus on architecture technology learning and sharing , Career and cognitive upgrading

Insist on sharing the dry goods of the earth , Looking forward to growing with you

---

「 The road to the advanced architecture 」 Focus on Architecture Research , Technology sharing

spot “ Fabulous ” and “ Looking at ” Oh

This article is from WeChat official account. - The road to the advanced architecture （jiagou_jingjin）.
If there is any infringement , Please contact the [email protected] Delete .
Participation of this paper “OSC Source creation plan ”, You are welcome to join us , share .