Thoughts on domain-driven models and data-centric Models

Suppose there is the following business logic: I want to move to a new place to work. Code 1: class player {public: void setaddr (string name); void setjob (string job); Private: String _ name; string _ job;} Code 2: class player {public: void changeaddr (string name); void changejob (string job); Private: String _ name; string _ job;} see the preceding two examples, it seems that the interface name is different, but it actually contains the difference between the data-centric model and the domain-driven model. A data-centric model focuses on data. When there are many data attributes, it is difficult for a customer program to determine how many data attributes a business needs, in addition, it is easy to cause code amnesia (it is difficult to judge the real business logic through the Code). In this case, it takes a lot of effort to map data to the business logic. The above code 1 is an example of a data-centric model. It is not so much a business logic service as a data holder, because the two interfaces do not have a real business significance, it only provides a way to change or store data. 2. the domain-driven model advocates focusing on the business logic and focusing on the object behavior, that is, the business behavior logic. It advocates reflecting the most valuable business logic. The above Code 2 is an example of the domain-driven model. The focus of the two models determines that setaddr is used when defining the migration and Failover behavior, setjob: the behavior that represents data without actual business value is the difference between changeaddr and changejob, which represents the actual business logic. Thinking: 1. But if we define object behavior with actual business value, how can we solve the behavior flooding caused by the simultaneous essential behavior of multiple business logic? For example, if I am unemployed or retired and need to set _ job to null at this time, changejob can no longer represent this business logic. I need to use losejob () or retire (), however, the essence of these operations is to set the job. In this case, three job operations are derived, and all these operations are setjob operations. This may require the team to define a general language. I think the application layer should be divided into application logic support layer and application logic implementation layer. The support layer defines some common logical objects and actions, and the Implementation Layer is responsible for combining common logical objects and actions to complete logical functions. However, the common objects and behaviors here are not anemia objects and behaviors that do not have actual business value. Therefore, the team needs to create a universal language for the domain model. 2. But can the object and behavior of anemia be completely removed from a complete project? What if I want to create a common module for several projects? How can the domain model resolve the conflict between this universality and business value? Or does such a general module need to define its own business scope and logic, rather than limited to this project? Continue learning...