Concept of Domain Model

Since Martin Fowler's DDD (domain driven develop
After the proposal, countless people began to criticize the persistent entity classes in the ORM mode. The entity classes in this mode were "anemia, lack of rich business semantics. In fact, they all made a basic logical error.
-Steal the concept.

How is the concept stolen? Please note that domain
Model) is a concept of business modeling. He has nothing to do with software development. Even if an enterprise does not develop software, he also has his business model, the business models of all enterprises in the same industry must have great commonalities and inherent regularity. The business models of enterprises in this industry are then abstracted from the business models of the entire industry, this is the "domain model ". A software company that has mastered the industrial domain model does not need to develop projects for others, and does not need to rely on software development to support itself, you have made a huge profit by providing business consulting to enterprises in this industry. For my current part-time company, it is such a software company that has accumulated enough Domain Models in the industry and set up a specialized consulting department. All of these departments are consultants, regardless of software development, they do not understand software development. They specifically teach customers in this industry how to do their own business. They are better at Customer business than customers, business Consulting alone can bring a lot of revenue to the company.

What about software development? The software developed by a software company that has no experience in the industry is basically demand-driven, rather than domain model-driven. Only companies that have accumulated Domain Models are eligible to talk about domain model-driven software development. From a domain model to a certainProgramming LanguageFor example, when Java is implemented, it will never be a correspondence, even the coarse-grained ejb2 model cannot do it. Let alone a pojo model with more emphasis on Fine Granularity? Use an object-oriented language such as Java to compile a domain model. If you use an ejb2 model, you need to use at least two ejbs, that is, one
Session Bean, processing process-oriented control logic, an entity bean, processing persistence-oriented entity logic (persistent operations are attached to entity
Bean ). For more complex domain models, you need more ejbs. Maybe a domain model requires multiple entity beans and multiple sessions.
Bean. Now we use the implementation based on the pojo model, so the coarse-grained EJB will continue to be subdivided: An entity
Bean needs to strip at least three pojo, that is, one or more entity classes, one or more Dao interface classes, one or more Dao interface implementation classes, and one session
Beans must be split into multiple service beans.

Finally, we can see how the concept was stolen and replaced by a Java persistent entity class. However, we should see that the anemia domain model criticized by Martin is not a hibernate entity type. Martin refers to the anemia domain model which is actually a domain abstract model that lacks rich business logic concepts, this is totally different from the hibernate entity class. The Hibernate entity class is only a class of pojo-based objects written to implement a domain model in the specific encoding process to complete a certain feature of the domain model. The complete features of this domain model should not be completed by a very coarse-grained single class, but by a group of Cooperative Classes: that is, the entity class of hibernate maintains the state of the domain model; Dao interface implements the class to complete the persistent operation of the domain model; Spring
Bean class implements the logic control function of the domain model.

Pojo refers to a non-EJB heavyweight, highly invasive component model. You can also find the pojo definition on Martin Fowler's bliki.

Is spring bean pojo? Yes!
Is the entity of hibernate pojo? Yes!

Is the DaO interface pojo? Yes!
Is EJB pojo? No!

I have never seen Martin's DDD. According to my own understanding, pojo
Domain Models refers to a lightweight domain model. What is lightweight? Is every feature, attribute, and logic of the domain model put into a class called Lightweight?

I think,Martin criticized the anemia domain model as focusing only on the persistent features of the domain model, while ignoring other features of the domain model.Such a model is anemia. This model only focuses on the external performance of the model at the technical level. That is to say, it only focuses on data access operations, while ignoring the core business value of the model.

For example, we compile a banking software. If you only pay attention to account addition, deletion, modification, and query, this is called anemia! In fact, you should pay attention to the business characteristics of the account, rather than the data features. You should focus on the business opened by the account, the business canceled by the account, the business transferred by the account, and so on, this is the domain model. For the simplest business, you may only add, delete, modify, and query the account class. However, for complex businesses, he is not just a class, but a simple operation of a table, such as opening an account, you need to accept the service fee, and check your personal financial status, now you need a group of Cooperative Classes.

Martin mentioned the domain model to emphasize that we should pay attention to the business of software and the internal laws of industry knowledge. He also modeled this pattern as a domain model and criticized it for obtaining a software, in my mind, I think of the person who adds, deletes, modifies, and queries the database. This has nothing to do with our Hibernate Persistence class!

My opinion is: an abstract domain model has many features. You need to use a group of collaborative classes to complete it, each or a group of classes undertakes a feature of this domain model. For example, for a domain model, such as the above account, you need a set of Hibernate Persistence classes: including the account class, user class, finance class, a group of springbean classes, accountmanager, financemanager, A set of Dao interfaces and implementation classes. These pojo classes work together to complete this domain model. If you only pay attention to account addition, deletion, modification, and query, it will be anemia. if you pay attention to the Account's business rules and consider a group of Cooperative Classes to complete it, it is not anemia.

I think that this is the most co-occurrence interpretation of the domain model concept during this search period ..

 There are also two
Summarize the recent Domain Information
Object and related discussions

Once again, I will summarize various points of view on the domain model.

Technically speaking, for the spring/hibernate architecture, Martin's rich domin
The model has become feasible. Let's take a look at what domain models are available and their advantages and disadvantages:

I. Blood Loss Model

See the blood loss model.
Http://forum.javaeye.com/viewtopic.php? T = 11712

To put it simply, domain object only has the getter/setter method of the attribute and does not have any business logic.

Ii. Anemia Model

For more information about the anemia model, see
Http://forum.javaeye.com/viewtopic.php? T = 11712

Domain ojbect contains the domain logic that does not depend on persistence, and the domain logic that depends on persistence is separated to the service layer.

Service (business logic, transaction encapsulation) --> Dao ---> domain object

Advantages of this model:

1. One-way dependency at each layer, clear structure, easy implementation and maintenance
2. Simple Design and stable underlying model
Disadvantages of this model:
1. Domain
The persistence domain logic of objects is separated to the service layer, which is not oo
2. The service layer is too heavy

Iii. Congestion Model
The congestion model is similar to the second model. The difference is how to divide the business logic, that is, most of the business logic should be placed in the domain
Objects (including persistence logic), and the service layer should be a thin layer, which only encapsulates transactions and a small amount of logic and does not deal with the DaO layer.
Service (transaction encapsulation)
---> Domain object <---> Dao

Advantages of this model:
1. More in line with OO principles

2. The service layer is thin. It only acts as a facade and does not deal with Dao.
Disadvantages of this model:
1. DAO and domain
Objects form bidirectional dependencies. Complex bidirectional dependencies can cause many potential problems.

2. How to divide the service-layer logic and the domain-layer logic is very vague. In actual projects, due to horizontal differences between the design and developers, the entire structure may be disordered and unordered.

3. Considering the transaction encapsulation feature of the service layer, the service layer must
The logic of the object provides the corresponding transaction encapsulation method. The result is that the service completely redefines all domain names.
Logic is very cumbersome, and the transactional encapsulation of the service is equivalent to converting the domain logic of OO into the service
Transactionscript. The oo implemented by the congestion model on the domain layer becomes a procedural layer. For the web layerProgramFrom the perspective of members, there is no difference with the anemia model.

Iv. bloat Model
Based on the third disadvantage of the congestion model, some people proposed to simply cancel the service layer, leaving only domain
The object and Dao layers encapsulate transactions on the domain logic of the domain object.
Domain object (transaction encapsulation, business logic)
<---> Dao
It seems that Ruby on Rails is such a model. He even merged domain object and Dao.
Advantages of this model:

1. Simplified layering
2. It is also in line with OO
Disadvantages of this model:
1. Many service logic that are not domain logic are also forcibly put into domain
Object, causing instability of the domain ojbect Model
2. Excessive information exposed to the web layer by domain object may cause unexpected side effects.

Among the four models, the blood loss model and the bloating model should not be promoted. Both the anemia model and the congestion model are technically feasible. However, I personally advocate the use of the anemia model. The reason is:

1. Refer to the third disadvantage of the congestion model. Because service transaction is obtained by the web layer program
For Web-layer programmers, the underlying oo meaning is lost.

2. Refer to the third disadvantage of the congestion model. For transaction encapsulation, the service layer must provide
Logic provides a procedural encapsulation, Which is cumbersome for programming.

3. Domain
The two-way dependency between objects and Dao is in a large project. Considering the level differences of team members, it is easy to introduce unpredictable bugs.

4. How to divide domain
Logic and service
The logic standards are uncertain. based on personal experience, some people think that a business is closer to the domain, and some people think that the business is closer to the service. Due to the uncertainty of the division criteria, the consequence is that there will be many such disputes and disputes in the actual project, and different people will have different division methods, in the end, the logic hierarchy of the entire project is disordered. Unlike the criteria I proposed in the anemia model for determining whether the model depends on persistence, such criteria are very definite and will not cause controversy. Therefore, such problems will not occur during team development.

5. domain of the anemia model
The object is really rich enough, but we are doing projects, not research, it's easy to use. Is it so pure OO? In fact, I do not agree with firebody's idea that the anemia model is designed and implemented.CodeThere is a lot of saying. When a design model is implemented, you get two classes: one entity class and one control class.

Ruby on Rails is a bloat model because it combines domain objects and Dao.

I think ror is a table module + activity record, which is somewhat different from the situation applicable to Java. The activity record architecture is used. During persistence, the syntax seems to be more Oo, which is directly obj. Save (), instead of Dao, save (OBJ)

Switch from Network