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

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

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

ORM作為模型對(duì)象與數(shù)據(jù)庫(kù)模型之間的接口，它的引入無(wú)疑承擔(dān)了實(shí)體領(lǐng)域模型所能稱(chēng)之為領(lǐng)域模型的 所有責(zé)任。 正如同Martin Fowler所說(shuō)的，貧血的領(lǐng)域模型承擔(dān)了領(lǐng)域模型的所有成本，卻沒(méi)有得到真正的收益。
在這里，真正的收益應(yīng)該是指高內(nèi)聚低耦合的擁有復(fù)雜對(duì)象行為的領(lǐng)域模型，確實(shí)，我們?cè)O(shè)計(jì)的領(lǐng)域模型根本沒(méi)有實(shí)現(xiàn)任何的功能，我們只能在外面從新設(shè)計(jì)一個(gè) Service Layer來(lái)管理所有的行為。

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

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


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

考慮這么一個(gè)層次：

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

     

}

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

2) 領(lǐng)域模型對(duì)象負(fù)責(zé)對(duì)自身的領(lǐng)域邏輯進(jìn)行封裝。

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

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