Has DDD surpassed MVC

original text : All talking DDD, Where on earth has it surpassed MVC?

Preface

If you want to have a deep understanding of DDD Core of Domain Driven Design , In any case, there are two more abstract concepts ——“ Anemia model ”、“ Congestion model ”：

• The anemia model is the transaction script model .
• The congestion model is the domain model pattern .

Anemia model

The anemia model was first widely used because EJB2, The strongest period is the period of Spring create , take ：

• “ Behavior ”（ Logic 、 The process ）;
• “ state ”（ data , The corresponding language is the object member variable ）.

Separate into different objects ：

• Objects with only states are called “ Anemia target ”（ Often called VO——Value Object）;
• Only the object of action is , Our common N In the layer structure Logic/Service/Manager layer （ Corresponding to EJB2 Medium Stateless Session Bean）.

—— once Spring The author of Rod Johnson It is also acknowledged that ,Spring It's just following EJB2 In the era of “ Transaction script ”, Process oriented programming .

The anemia domain model is an anti pattern that has existed for a long time , There are still a lot of fans .

Martin Fowler Once and Eric Evans When talking about it , It seems that this model is becoming more and more popular . As a promoter of the domain model , They don't think it's a good thing .

The basic characteristics of the anemia domain model are ： It really looks like this at first sight . There are many objects in the project , They are all named according to their domain . There are plenty of connections between objects , Very similar to the real domain model . But when you look at the behavior of these objects , You'll find that they basically don't have any behavior , It's just a bunch of getter/setter.

Actually , These objects were defined at the beginning of the design to contain only data , You can't add domain logic ; The logic is written into a group called Service The object of ; and Service Is built on the domain model , You need to use these models to pass data .

The horror of this anti pattern is ： It's completely against object-oriented design . Object oriented design advocates binding data and behavior together , The domain model is more like process oriented design ,Martin Fowler and Eric stay Smalltalk I strongly oppose this kind of practice . What's worse is , Many people think that these objects are real objects , So the meaning of object-oriented design is misunderstood .

Now , The concept of object orientation has spread widely , We should oppose this kind of anemia domain model , More evidence is needed . The fundamental problem with the anemia domain model is , It introduces all the costs of domain model design , But it didn't bring any benefits . The main cost is mapping objects to the database , And then there's a O/R（ Object relationship ） Mapping layer .

Only when you make full use of object-oriented design to organize complex business logic , This cost can be offset . If you write all the behaviors to Service object , So you end up with a set of transaction scripts , Thus missing out on the benefits of the domain model . just as martin In the book enterprise application architecture pattern , Domain models are not necessarily the best tools .

Put behavior into the domain model , This point and layered design （ Domain layer 、 Persistence layer 、 Display layer, etc ） Not conflict . Because the domain model contains domain related logic —— verification 、 Calculation 、 Business rules, etc . If you want to discuss whether you can put data sources or presentation logic into a domain model , This is beyond the scope of this paper .

The views of some object-oriented experts are sometimes confusing , They think there really should be a process oriented service layer . however , This doesn't mean that domain models shouldn't contain behaviors . in fact ,service Layers need to be used in conjunction with a set of behavior rich domain models .

Eric Evans Of Domain Driven Design It is mentioned in the book ：

application layer （ namely Service layer ）

Describe what the application does , And schedule rich domain models to do it . The task at this level is to describe the business logic , Or interact with the application layer of other projects . This layer is very thin , Does not contain any business rules or knowledge , It is only used to schedule and distribute tasks to the next layer of domain model . There is no business state in this layer , But it can provide task status for users or programs .

Domain layer （ Or model layer ）

Represents the business logic 、 Business scenarios and rules . This level controls and uses the business state , Even if these states are eventually stored in the persistence layer . All in all , This layer is the core of the software .

The service level is very thin —— All the important business logic is written in the domain layer . He restated this point in the service model ： The common mistake people make today is that they don't want to spend time putting business logic into the right domain model , So as to gradually form process oriented programming .

I don't know why this antipattern is so common . I suspect it's because most people don't use a well-designed domain model , Especially the data centric developers . Besides , Some technologies will also drive this antipattern , such as J2EE Of Entity Bean, It makes me more inclined to use POJO Domain model .

All in all , If you put most of your behavior in the service layer , Then you lose the benefits of the domain model . If you put all your behavior in the service layer , Then you're hopeless .

advantage

Simple ：

• For applications with only a small amount of business logic , It's very natural to use ;
• Rapid development , Easy to understand ;
• Be careful ： We can't totally exclude this way .

shortcoming

Can't deal with complex logic well ：

• For example, the revenue recognition rules have changed , For example, in 4 month 1 The contract signed before the No ……
• Contracts with Europe use another rule ……

Congestion model

The essence of object-oriented design is ：“ An object has state and behavior ”.

Like a person ：

• What kind of eyes he has, what kind of nose he has, that's the state ;
• People can play games or write programs , This is behavior .
• Why should there be one “ people Manager” Such things exist to help people “ Play the game ” Well ？ Take a simple one J2EE Case study , Design one with the user （User） Related functions .

The traditional design is ：

• class ：User+UserManager;
• Save user calls ：userManager.save(User user).

The congestive design might be ：

• class ：User;
• Save user calls ：user.save();
• User One behavior is ： Save itself .

In fact, they don't have any special direction , Individuals tend to use the congestion model all the time , because OOP There is always more semantics than process oriented programming 、 Better organization 、 More maintainability — Of course, it's more difficult to master .

Therefore, in the actual engineering scene , Whether to use , How to use it also depends on the understanding and grasp of the designer and the team , Because now the vast majority of J2EE Developers are deeply influenced by the anemia model . in addition , The congestion model is used in the actual engineering scene , There will be a lot of details , The biggest hurdle is “ How to design congestion model ” Or say “ How to separate proper and semantic logic from complex business VO In the act of ”.

If an object contains other objects , Then continue to delegate responsibility , By specific POJO Execute business logic , Fine grained policy patterns , Rather than writing ifelse.