如今采用Hibernate實現(xiàn)的Domain Model，多數(shù)只是維護實體之間的關聯(lián)，而大多數(shù)的業(yè)務邏輯，則是由Service Layer來實現(xiàn)。

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

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

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

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

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


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

考慮這么一個層次：

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);{
     }

     

}

這樣作的問題是與建立貧血對象模型相比，領域?qū)ο竽Ｐ偷男袨橥ㄓ眯枰猄erviceLayer來完成，約定：
1）ServiceLayer層只負責實現(xiàn)簡單的單步驟的與底層數(shù)據(jù)庫訪問的 邏輯，不包含任何業(yè)務領域邏輯。 如上面的 service.save(),service.update, service.delete , service.findGroupByName.... 

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

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

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