still is
The aftershocks caused by the PEAA of Martin Fowler, this book is indeed surprising. Anemia Domain Model, "In this area, there is a bunch of objects named by noun. There are also rich association between these objects, just like the true domain model. However, these objects have too little behavior. The domain logic is placed in Service Layer and accesses the database through the domain object. "(Clear space)
The Martin Fowler flag is clearly opposed, its reason is: "Basically, the problem of anemia is the problem of it pays all the costs of the domain model, but there is no income", the cost, mainly from model and relational database The interface between the interface must be added with an ORM tool. What is the revenue of the real domain model? From macro, it is possible to cope with complex business logic requirements, micro-top, can use inheritance and polymorphism, etc., the data and behavior are good, resulting in a beautifully pursuit of OO enthusiasts. The following is a little idea I personally, "the stealing model": anemia model is close to a static data model (ER model, or PowerDesigner's CDM), if this database design is close to OO ideas (a longible The storage plan), then the cost of the ORM is not high. If you are using a domain model that truly combines behavior, complex design patterns are used, and there are many auxiliary classes, control classes, which obtained the flexibility on business processing, very It meets the opening and closing principle, but there is increasing the increasing map of the database, the anemia model is not guilty, should choose the actual demand and its own design capabilities, I have encountered projects (including other companies), 80 % Use transaction footbook architecture and anemia models, quite a few successful cases. Everything is subject to demand, and the principle of OO is fully considered. Details in the architecture take practice as the only standard for inspection, and the enemy is made by the enemy.
