Domain Model (four types)

To make up for your regrets, I would like to summarize some of Robbin's domain model points and their supplements. In my website and speeches, Robbin initially divided Domain Models into four categories:
1. Blood Loss Model
2. Anemia Model
3. Congestion Model
4. bloat Model

Let's take a look at the specific content of these domain models and their advantages and disadvantages:

I. Blood Loss Model

In simple terms, the blood loss model is a pure data class that only has the getter/setter method of the attribute in the domain object. All business logic is completely completed by the Business Object (also known

In this model, domain object is called "anemia domain object" by Martin Fowler ". The following uses a specific code to describe the code.

From Hibernate's caveatemptor, but after my rewriting:

An object class is called item, which refers to an auction project.
A Dao interface class is called itemdao
A Dao interface implementation class is called itemdaohibernateimpl
A business logic class is called itemmanager (or itemservice)

Java code:

Public class item implements serializable {
Private long id = NULL;
Private int version;
Private string name;
Private user seller;
Private string description;
Private monetaryamount initialprice;
Private monetaryamount reserveprice;
Private date startdate;
Private date enddate;
Private set categorizeditems = new hashset ();
Private collection bids = new arraylist ();
Private bid successfulbid;
Private itemstate state;
Private user approvedby;
Private date approvaldatetime;
Private date created = new date ();
// The getter/setter method is omitted without writing, so it is too long.
}

Java code:

Public interface itemdao {
Public item getitembyid (long ID );
Public Collection findall ();
Public void updateitem (item );
}

Itemdao defines the persistence operation interface, which is used to isolate the persistence code.

Java code:

Public class itemdaohibernateimpl implements itemdao extends hibernatedaosupport {
Public item getitembyid (long ID ){
Return (item) gethibernatetemplate (). Load (item. Class, ID );
}
Public Collection findall (){
Return (list) gethibernatetemplate (). Find ("from item ");
}
Public void updateitem (item ){
Gethibernatetemplate (). Update (item );
}
}

Itemdaohibernateimpl is used to complete specific persistence work. Note that the acquisition and release of database resources are handled in itemdaohibernateimpl. each DAO method is called

Open the session, and close the session after the DAO method is called. (The session is placed in threadlocal to ensure that only one call is enabled and closed once)

Java code:

Public class itemmanager {
Private itemdao;
Public void setitemdao (itemdao) {This. itemdao = itemdao ;}
Public Bid loaditembyid (long ID ){
Itemdao. loaditembyid (ID );
}
Public Collection listallitems (){
Return itemdao. findall ();
}
Public Bid placebid (item, user bidder, monetaryamount bidamount,
Bid currentmaxbid, bid currentminbid) throws businessexception {
If (currentmaxbid! = NULL & currentmaxbid. getamount (). compareto (bidamount)> 0 ){
Throw new businessexception ("bid too low .");
}

// Auction is active
If (! State. Equals (itemstate. Active ))
Throw new businessexception ("auction is not active yet .");

// Auction still valid
If (item. getenddate (). Before (new date ()))
Throw new businessexception ("can't place new bid, auction already ended .");

// Create new bid
Bid newbid = new bid (bidamount, item, bidder );

// Place bid for this item
Item. getbids (). Add (newbid );
Itemdao. Update (item); // call Dao to complete the persistence operation
Return newbid;
}
}

Transaction Management is completed at the itemmanger layer. itemmanager implements specific business logic. In addition to common simple logic related to crud, there is also a placebid

Logic, that is, the project bidding.

The above is a complete sample code for the first model. In this example, all the business logic such as placebid, loaditembyid, and findall are implemented in itemmanager.

Item only has the getter/setter method.

Ii. Anemia Model

Simply put, domain ojbect contains domain logic that does not depend on persistence, and those that rely on persistence are separated to the service layer.
Service (business logic, transaction encapsulation) --> Dao ---> domain object
This is the rich domain object that Martin Fowler refers.

An entity class with business logic, that is, domain object is an item
A Dao interface itemdao
One Dao implements itemdaohibernateimpl
Itemmanager, a business logic object

Java code:

Public class item implements serializable {
// All attributes are the same as those of the getter/setter method.
Public Bid placebid (User bidder, monetaryamount bidamount,
Bid currentmaxbid, bid currentminbid)
Throws businessexception {

// Check highest bid (can also be a different strategy (pattern ))
If (currentmaxbid! = NULL & currentmaxbid. getamount (). compareto (bidamount)> 0 ){
Throw new businessexception ("bid too low .");
}

// Auction is active
If (! State. Equals (itemstate. Active ))
Throw new businessexception ("auction is not active yet .");

// Auction still valid
If (this. getenddate (). Before (new date ()))
Throw new businessexception ("can't place new bid, auction already ended .");

// Create new bid
Bid newbid = new bid (bidamount, this, bidder );

// Place bid for this item
This. getbids. Add (newbid); // please note that this statement is transparent and persistent, but itemdao cannot be called here. item cannot generate itemdao.

Dependency!

Return newbid;
}
}

The bid business logic is put into the item. Please note this. getbids. Add (newbid); without the support for o/R Mapping such as hibernate or JDO, we cannot implement

Now this transparent persistence behavior. However, please note that itemdao cannot be called in the item to generate dependency on itemdao!

The Code of itemdao and itemdaohibernateimpl is the same as above, and is omitted.

Java code:

Public class itemmanager {
Private itemdao;
Public void setitemdao (itemdao) {This. itemdao = itemdao ;}
Public Bid loaditembyid (long ID ){
Itemdao. loaditembyid (ID );
}
Public Collection listallitems (){
Return itemdao. findall ();
}
Public Bid placebid (item, user bidder, monetaryamount bidamount,
Bid currentmaxbid, bid currentminbid) throws businessexception {
Item. placebid (bidder, bidamount, currentmaxbid, currentminbid );
Itemdao. Update (item); // you must call Dao explicitly to ensure persistence.
}
}

In the second model, the placebid business logic is implemented in item, while the loaditembyid and findall business logic are implemented in itemmanager. However, it is worth noting that

Yes. Even if the placebid business logic is placed in the item, you still need to encapsulate a layer in itemmanager to ensure Transaction Management and persistence of the placebid business logic.

Trigger.

This model is the real domain model referred to by Martin Fowler. In this model, there are three business logic methods: placebid, loaditembyid, and findall.

Which logic should be placed in item and itemmanager. In our example, placebid is placed in item (but itemmanager also needs to perform

(Simple encapsulation), loaditembyid and findall are placed in itemmanager.

What is the principle of splitting? Rod Johnson proposed the principle of "case by case", which is highly reusable and closely related to the domain object state in item, with low availability.

Is not closely associated with the domain object status in itemmanager.

After the above discussion, how to distinguish domain logic from business logic, I would like to propose an improved differentiation principle:

Domain logic should only be related to the instance status of this domain object, rather than the status of a batch of domain objects;

After you put a logic in the domain object, the domain object should still be independent of the persistence layer framework (hibernate, JDO), and the domain object can still be

This domain object is still a complete, self-contained domain object that does not depend on the external environment. In this case, this logic

Domain logic.
Here is a very certain principle: Whether logic is only related to the state of this object, if it is only related to this object, it is domain logic; if logic is related to a batch of Domain

The object state is related, not domain logic, but business logic.

The business logic method placebid of item does not explicitly depend on the persistent itemdao interface, so it should be placed in item. Note that if the persistence is removed from hibernate

Framework, the domain object of item can be tested in units, and does not rely on the persistence mechanism of hibernate. It is an independent, portable, complete, and self-contained

Domain object.

The loaditembyid and findall business logic methods must explicitly depend on the persistent itemdao interface. Otherwise, the business logic cannot be completed. If you want

If the methods are put in items, items cannot be separated from the Hibernate framework and cannot exist independently outside the Hibernate framework.

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. The persistence domain logic of domain object 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 to say, most of the business logic should be placed in the domain object (including the persistence logic)

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
This model combines the domain object and Business Object of the second model into one. So itemmanager is not needed. In this model, there are only three classes.

They are:

Item: Contains entity information and all business logic.
Itemdao: Persistent Dao Interface Class
Itemdaohibernateimpl: Dao interface implementation class

Because itemdao and itemdaohibernateimpl are identical to the above, they are omitted.

Java code:

Public class item implements serializable {
// All attributes and the getter/setter method are omitted.
Private Static itemdao;
Public void setitemdao (itemdao) {This. itemdao = itemdao ;}

Public static item loaditembyid (long ID ){
Return (item) itemdao. loaditembyid (ID );
}
Public static collection findall (){
Return (list) itemdao. findall ();
}

Public Bid placebid (User bidder, monetaryamount bidamount,
Bid currentmaxbid, bid currentminbid)
Throws businessexception {

// Check highest bid (can also be a different strategy (pattern ))
If (currentmaxbid! = NULL & currentmaxbid. getamount (). compareto (bidamount)> 0 ){
Throw new businessexception ("bid too low .");
}

// Auction is active
If (! State. Equals (itemstate. Active ))
Throw new businessexception ("auction is not active yet .");

// Auction still valid
If (this. getenddate (). Before (new date ()))
Throw new businessexception ("can't place new bid, auction already ended .");

// Create new bid
Bid newbid = new bid (bidamount, this, bidder );

// Place bid for this item
This. addbid (newbid );
Itemdao. Update (this); // call Dao for explicit persistence
Return newbid;
}
}

In this model, all business logic is in item, and transaction management is also implemented in item.

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 object 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 provide corresponding transaction encapsulation methods for the logic of all domain objects, the result is that the service completely redefines all domain logic, which is very cumbersome, and the transactional encapsulation of the service is equivalent to converting the domain logic of OO to the service transactionscript in the process.

The oo implemented by this congestion model on the domain layer has become a procedural model on the service layer. From the perspective of web-layer programmers, there is no difference with the anemia model.

1. transactions are not managed by items, but by containers or business classes at a higher level.

2. if the item is not managed from the persistent layer, such as the PM of JDO, itemdao. update (this); is not required. That is to say, items are obtained from the database during the transaction process, and the declaration cycle does not exceed the scope of the current transaction.

3. if the item is out of the persistence layer, that is, if the lifecycle of the item is beyond the scope of the transaction, it must be shown that the persistence method such as update or attach is called, in this case, it should be based on the 2nd models mentioned by Robbin.

Iv. bloat Model

Based on the third disadvantage of the congestion model, some people proposed to simply cancel the service layer, leaving only two layers of domain object and Dao, and encapsulate transactions on the domain logic of 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 placed 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.

From: http://blog.csdn.net/onlyzhangqin/archive/2008/03/27/2222477.aspx