Anemia models and congestive models

http://www.raychase.net/238

These two concepts are the two common model design types that Martin Fowler summed up earlier, not saying who is good or bad, and choosing the right scenario for different model categories is the work of the designer. There is no problem with the tool itself, only the problem of the tool user.

anemia model refers to the domain object only get and set method (POJO), all business logic is not included inside but placed in the logic layer.

The advantage is that the hierarchy of the system is clear, with one-way dependencies between the layers,client-> (business facade)->business Logic->data Access Object. It can be seen that domain objects are used almost exclusively for transmission media and do not affect the division of hierarchies.

The disadvantage of the model is that it is not enough object-oriented, the domain object is only used as a state of preservation or delivery state, it is lifeless, only the data does not have the behavior of the object is not the real object, in business logic to deal with all the operational logic, for fine-grained logical processing, By adding a layer of facade to achieve the effect of the façade packaging.

When using spring, it is often implied that you are using an anemic model, and we use domain classes to store data simply, and spring does not control the injection and management of these classes, the logical layer of spring's concern (such as the Singleton pooled business Logic layer) can be designed as a singleton bean.

If we were to do this in the same way as we do in the domain class, we would encounter a lot of trouble when we use spring to construct such a data bean, such as a reference between beans, which could cause a call to a nested constructor between a wide range of beans.

Anemia model implementation of the biggest difficulty lies in how to comb the business logic layer within the division of the relationship, because the layer will be relatively large, the border is not easy to control, the internal dependencies between the various modules are not easy to manage, you can consider such a realization of the idea:

• (1) Laying flat atomic business logic layer, that is, simple crud operation (including batch data operation);
• (2) Clear logic for a particular business is achieved by assembling atomic operations through the facade layer.
• (3) To implement the module division of the business Logic layer, and maintain the loosely coupled relationship between the modules.

To illustrate:

The Atomic Business Logic Layer (service) provides a conditional query method for the user model:

List<user> queryuser (Condition con)

The facade layer provides a molecular interface for a specific business scenario that satisfies a 18-year-old Chinese citizen, which is the atomic interface that the internal implementation invokes:

List<user> Queryadultchinese ()

The facade and service layers are divided vertically into several large domain bundles: users, content, and products.

The congestion model hierarchy is similar to the above, but most of the business logic and persistence are placed in domain object, which simply encapsulates part of the business logic and controls transactions, permissions, and so on, so that the hierarchy becomes client-> (Business facade)->business Logic->domain object->data Access Object.

It has the advantage of being object-oriented, and business logic is a single responsibility, unlike the anemia model, which contains all the logic that is too heavy.

The downside is how to divide the business logic, what logic should be placed in domain object, and what business logic should be put in the logical, which is very vague. Even if the business logic is divided, it is not possible to better sub-module development because it is dispersed in the businesses logic and domain object layers.  Developers who are familiar with business logic need to penetrate into domain logic, and Domian logic also contains persistence, which is confusing for developers. Second, if business logic is to control the transaction and provide a uniform service invocation entry point for the upper layer, it must re-wrap all the operational logic implemented in domain logic and be entirely repetitive.

With ROR development, each domain model object can have its own underlying business approach, usually satisfying the characteristics of the congestion model. The congestion model is more suitable for the design and development of more complex business logic.

The hierarchy of the congestion model and the partitioning of the modules are a science, and the requirements for developers are also high, so consider defining some of these rules:

• (1) Transaction control is not implemented in the object of the domain model, and can be done in facade.
• (2) in the domain model object, only the general method driven by this model is retained, and the special scene method calls with obvious business features are facade.

Everything is not absolute and there are some seemingly difficult problems to solve. For example, given the need for performance, I need to query a product that satisfies a certain condition at a time, and they are linked by ordering the relationship between them, and it may be found that the above model hierarchy is not solved.

What do we do? Including all the above, we welcome the discussion.

Anemia models and congestive models