We usually do business development for Web projects, most of which are based on the MVC three-tier architecture of the anemia model, which is a typical process-oriented programming style. On the contrary, the DDD development model based on the congestion model is a typical object-oriented programming style. However, DDD is not a silver bullet. For system development with uncomplicated business, the traditional development model based on the anemia model is simple and sufficient, while the DDD development model based on the congestion model is a bit overkill and cannot work. On the contrary, for business complex system development, the DDD development model requires more time and energy in the design to improve the reusability and maintainability of the code, so it is more than the development model based on the anemia model. There are advantages.
Compared with the traditional development model, the main difference between the DDD development model based on the congestion model is the Service layer. In the development model based on the congestion model, we moved part of the original business logic in the Service class to a congested Domain domain model, so that the implementation of the Service class depends on this Domain class. In the DDD development mode, the Service class will not be completely removed, but is responsible for some functions that are not suitable for being placed in the Domain class. For example, it is responsible for non-functional work such as dealing with the Repository layer, business aggregation functions of cross-domain models, and idempotent transactions. Compared with the traditional development model based on the anemia model, the DDD development model based on the congestion model has basically the same code in the Controller layer and the Repository layer. This is because the Entity life cycle of the Repository layer is limited, and the VO of the Controller layer is purely a DTO. The business logic of the two parts is not too complicated. The business logic is mainly concentrated in the Service layer. Therefore, the Repository layer and Controller layer continue to use the design idea of the anemia model is no problem.