background
- Recently, the company has begun to implement DDD ( Domain Driven Design ). The object-oriented development model based on the congestion model is one of the characteristics of DDD. In normal development, we all use the MVC architecture, which is a process-oriented development style based on the anemia model. The students will ask, what are the anemia models and the congestion models?
Anemia model and congestion model
Introduction
Anemia model :
- Define the simple attribute value of the object, there is no business logic method (personal understanding), no official explanation is found
Hyperemia model
- The congestion model means that when we define attributes, we also define methods. Our attributes can be directly obtained in some ways. Then we can embed methods in the object to directly create an object with attribute values. In other words, this object no longer requires us to perform further operations, which also compound the encapsulation of one of the three major characteristics of OOP (personal understanding)
About the relationship between DDD and hyperemia model
When we usually do web development, we define DTO, define the database Model, BO, etc., perform the get set method on it, then operate the Bo object through the service, and finally persist the database and DTO transmission through the copy attribute. But if it is a congestive model, you don't need to perform attribute assignment in the service, but when creating this object, perform business operations and assign its attribute values. This is the idea of DDD, and this object is the Entity or value defined by DDD. Service is domianService, which is composed of multiple Entity and value to construct the final domain model.
The following figure is the author's own understanding of DDD, and I hope it can help everyone understand:
Back to the topic or look at the congestion model and the anemia
model. What is the advantage of the congestion model in so many DDD thoughts? Which scenarios are applicable? And we are all using the anemia model, but we have no problems in our usual development?
Why is everyone using the anemia model?
- Using the traditional development model of the anemia model, the data and business logic are completely separated, and the object properties can be changed through the get set method, and the object properties can be modified at will. This also violates the encapsulation characteristics of the three major characteristics of OOP as mentioned above. Such a programming method is also a process-oriented programming method. The process-oriented programming method conforms to the logic of the human brain and does not need to use too many design patterns and excessive designs. There is also a very irresponsible sentence that people often say in development: "How convenient is it?", I have been stacking code, which is completely different from future scalability.That is to say, the programming method based on the anemia model is process-oriented programming. Human thinking logic is very consistent, and the programming process is also very convenient, so everyone is willing to accept this programming method.
- In summary:
- The design of the hyperemia model is more difficult than the anemia model
- It has become a habit that everyone consistently uses process-oriented programming based on the anemia model, and it is difficult to change thinking
- There is also an irresponsible attitude towards the code. (This is a common problem of most programmers)
Is the congestion model suitable for all scenarios?
- Using the congestion model is to use the development model of DDD based on the congestion model. The above has repeatedly emphasized that the congestion model is also a complicated definition model and difficult to design. The amount of code development may be more than other models. The main reason is that the design is difficult. That is to say, if we design a very simple business logic, do we still need such complex design ideas? And this business will not be complicated in subsequent iterations, so I personally think that we will use our process-oriented programming ideas based on the anemia model. Why complicate simple things. I suddenly thought of a paragraph I said at the same time:
- 普通程序员写hello word 直接print
- 高级程序员写hello word 各种设计模式各种可拓展最后输出hello word
- 技术专家写hello word ，直接打印hello word
- Of course, we are working on a complex business scenario, so we need to develop a DDD (domain-driven model) development model based on the congestion model. In fact, the development model of DDD is to fully follow the three major characteristics of OOP (or the four major characteristics, encapsulation, inheritance, polymorphism, (abstraction)). If it is the process-oriented programming of the anemia model, then the final result is point practice Lines, from lines to nets, are densely packed and unmaintainable. Therefore, complex business logic is developed based on the congestion model. But there is also the problem of class expansion, a class has a lot of code. This can still be solved, that is, through design patterns and business logic segmentation.
to sum up
- Simple explanation of anemia model and congestion model
- And the relationship between DDD development model and process-oriented programming and congestion and anemia models
- Compare the process-oriented programming paradigm of the MVC layer based on the anemia model and the object-oriented programming paradigm based on the congestion model
- The two models are suitable for that scenario
reference
- https://time.geekbang.org/column/article/169600 The beauty of design patterns
- https://zh.wikipedia.org/wiki/%E5%8F%8D%E9%9D%A2%E6%A8%A1%E5%BC%8F Negative mode
- http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html Basic theory of DDD