如今采用Hibernate實現的Domain Model，多數只是維護實體之間的關聯，而大多數的業務邏輯，則是由Service Layer來實現。

這樣的模型對象擁有的行為太少了，以至于Martin Fowler給他們下了一個定義：貧血模型。

我們知道，高內聚低耦合是衡量一個模型設計是否合理的重要標準之一。對象組件間合理分工協作可以解決復雜的問題邏輯，按照這個標準，我們似乎可以很自然的各種行為封裝到各個模型對象中。 然而，現在絕大多數的應用沒有這樣做。

ORM作為模型對象與數據庫模型之間的接口，它的引入無疑承擔了實體領域模型所能稱之為領域模型的 所有責任。 正如同Martin Fowler所說的，貧血的領域模型承擔了領域模型的所有成本，卻沒有得到真正的收益。
在這里，真正的收益應該是指高內聚低耦合的擁有復雜對象行為的領域模型，確實，我們設計的領域模型根本沒有實現任何的功能，我們只能在外面從新設計一個 Service Layer來管理所有的行為。

我不敢評論這樣的設計方案是怎樣的不合理。 當設計到擁有比較復雜問題領域模型的時候，這種只負責管理實體間關聯關系的實體模型肯定不能適應，這樣做的后果就是將復雜領域邏輯統統 移植到 Service Layer層或者胡亂給起名字的一個外層。

考慮Martin Fowler 《Analysis Patterns》中著名的一個通用模型：團體責任模型。里面的約束需要在實體領域模型中得以實現，在貧血領域模型中，封裝實現這樣的需要檢索 驗證某個甚至全部實體數據的行為只能移植到Service Layer中。 這樣的移植對于領域模型的構架無疑大大增加了復雜度。


那么，我們能不能在貧血領域模型基礎上，加入對象行為，使之擁有豐富的行為呢？ 我想這是可以解決的，解決的關鍵是將可訪問底層實體數據的行為賦予每一個實體模型對象，最簡便的辦法就是用一個全局訪問點來實現。

考慮這么一個層次：

public interface ServiceProvider{
                public Object getService(String serviceName);;
       
}


public ServiceProviderImpl{
              public ObjectgetService(String serviceName);{
             
                    return ServiceLocator.getService(serbiceName  );;
             }
               
}

public interface CRUD{
     public void save();;
      public void delete();;
       public void load(Long id);;
      public void update();;
}

public Group implements CRUD {

    private String name;
     private List  users;
      public GroupService getGroupService();{
           return (GroupService);getServiceProvider();.getService(this.class.getName();+"Service");
      }
     public void save();{
          if(getGroupService();.findGroupByName(name);!=null);
                       throw new RuntimeExepion("duplicate group name!");;
          getGroupService();.save(this);;
      }
      public  Group load(Long id);{
           this=getGroupService();.load(this.class,id);;
           return this;
      }
      
     public void addUser(user user);{
             
            users.add(user);;
            this.save();; 
     
    }
     public void removeUser(User user);{
     }

     

}

這樣作的問題是與建立貧血對象模型相比，領域對象模型的行為通用需要ServiceLayer來完成，約定：
1）ServiceLayer層只負責實現簡單的單步驟的與底層數據庫訪問的 邏輯，不包含任何業務領域邏輯。 如上面的 service.save(),service.update, service.delete , service.findGroupByName.... 

2) 領域模型對象負責對自身的領域邏輯進行封裝。

3）通過賦予模型對象行為，建立對象間行為關聯，以完成更復雜的 商業邏輯。

4）外層業務邏輯層只能看到領域模型對象，不能直接操作任何的類似Service.save這樣的直接訪問底層數據庫的行為。