自從Martin Fowler的DDD（Domain Driven Develop 領(lǐng)域驅(qū)動開發(fā)）提出來之后，無數(shù)的人就開始非議ORM方式下的持久化實體類，抨擊這種方式下的實體類是“貧血”的，缺乏豐富業(yè)務(wù)語義的。其實他們都犯了一個最基本的邏輯錯誤 － 偷換概念。
概念是如何被偷換的呢？請注意，領(lǐng)域模型（Domain Model）是一個商業(yè)建模范疇的概念，他和軟件開發(fā)并無一絲一毫的關(guān)系，即使一個企業(yè)他不開發(fā)軟件，他也具備他的業(yè)務(wù)模型，所有的同行業(yè)的企業(yè)他們的業(yè)務(wù)模型必定有非常大的共性和內(nèi)在的規(guī)律性，由這個行業(yè)內(nèi)的各個企業(yè)的業(yè)務(wù)模型再向上抽象出來整個行業(yè)的業(yè)務(wù)模型，這個東西即“領(lǐng)域模型”。一個掌握了行業(yè)領(lǐng)域模型的軟件公司，根本不需要再給人家開發(fā)項目了，根本不需要靠軟件開發(fā)養(yǎng)活自己了，你光給這個行業(yè)的企業(yè)提供業(yè)務(wù)咨詢已經(jīng)賺得非常豐厚的利潤了。以我現(xiàn)在兼職所在的公司來說，就是這樣一家軟件公司，在行業(yè)內(nèi)積累了足夠的領(lǐng)域模型，成立了一個專門的咨詢部門，這個部門下面都是咨詢師，他們是不管軟件開發(fā)的，也不懂軟件開發(fā)，他們就專門教這個行業(yè)的客戶，教他們怎么去做自己的業(yè)務(wù)，他們比客戶還精通客戶的業(yè)務(wù)，光是業(yè)務(wù)咨詢已經(jīng)可以為公司帶來很多的收入。
而軟件開發(fā)呢？一個并沒有行業(yè)經(jīng)驗積累的軟件公司，它開發(fā)的軟件，基本上完全是需求驅(qū)動，而不是領(lǐng)域模型驅(qū)動。只有具備了領(lǐng)域模型積累的公司才有資格去談領(lǐng)域模型驅(qū)動軟件開發(fā)。在由領(lǐng)域模型往某種編程語言如Java上來實現(xiàn)的時候，絕對不會是1:1的對應(yīng)關(guān)系，即使是粗顆粒度的EJB2模型都做不到，更不要說更加強調(diào)細(xì)顆粒度的POJO模型呢？用面向?qū)ο蟮恼Z言如Java來編寫一個領(lǐng)域模型，如果是用EJB2模型，你需要使用最少兩個以上的EJB，即一個 Session Bean，處理面向流程的控制邏輯，一個Entity Bean，處理面向持久化的實體邏輯（持久化操作附著在Entity Bean的Home接口上）。如果是更加復(fù)雜的領(lǐng)域模型，那么你需要更多的EJB，也許是一個領(lǐng)域模型需要多個Entity Bean和多個Session Bean?，F(xiàn)在我們使用基于POJO模型的實現(xiàn)，那么粗顆粒度的EJB還要繼續(xù)細(xì)分：一個Entity Bean要剝離出來至少三個以上的POJO，即一個或者多個實體類，一個或者多個DAO接口類，一個或者多個DAO接口實現(xiàn)類；一個Session Bean要切分為多個業(yè)務(wù)Bean。
由此我們終于看出來概念是怎樣被偷換的了，一個商業(yè)概念的抽象領(lǐng)域模型被一個Java持久化實體類替代了。但是我們應(yīng)該看到，Martin批評的貧血的領(lǐng)域模型并不是Hibernate實體類，Martin指的貧血的領(lǐng)域模型實際上是缺乏豐富業(yè)務(wù)邏輯概念的領(lǐng)域抽象模型，這和Hibernate實體類完全是風(fēng)牛馬不相及的東西。而Hibernate實體類只是具體編碼過程中，為了實現(xiàn)一個領(lǐng)域模型而編寫的一組基于POJO的對象中的，完成領(lǐng)域模型某個特征的類。而這個領(lǐng)域模型完整的特征并不應(yīng)該，也不可能由一個非常粗顆粒度的單類完成，而是由一組互相協(xié)作的類完成：即Hibernate的實體類保持領(lǐng)域模型的狀態(tài)；DAO接口實現(xiàn)類完成領(lǐng)域模型的持久化操作；Spring Bean類完成領(lǐng)域模型的邏輯控制功能。
POJO指的就是非EJB那種重量級，高侵入性的組件模型，關(guān)于POJO的定義，你同樣可以在Martin Fowler的bliki上面找到。
Spring的Bean是不是POJO？ 是的！
Hibernate的entity是不是POJO？是的！
DAO接口是不是POJO？是的！
EJB是不是POJO？ 不是的！
我沒有看過Martin的DDD，我按照自己的理解， POJO domain models指的就是輕量級的領(lǐng)域模型。何為輕量級？ 把領(lǐng)域模型的各個特征，各個屬性，各個邏輯都塞到一個class里面叫做輕量級嗎？
我認(rèn)為，Martin批評的貧血的領(lǐng)域模型是指只關(guān)注了領(lǐng)域模型持久化特征方面，而忽略了領(lǐng)域模型其他特征方面的模型，這樣的模型是貧血的。因為這種模型只關(guān)注了模型在技術(shù)層面的外在表現(xiàn)，也就是說只關(guān)注了數(shù)據(jù)的存取操作，而忽視了模型蘊含的業(yè)務(wù)核心價值。
舉例來說，我們編一個銀行軟件，如果你只關(guān)注了賬戶的增刪改查，這叫做貧血！而實際上你應(yīng)該關(guān)注的是賬戶的業(yè)務(wù)特征，而不是數(shù)據(jù)特征，你應(yīng)該關(guān)注的是賬號開立的業(yè)務(wù)，賬戶注銷的業(yè)務(wù)，賬號過戶的業(yè)務(wù)等等，這才是領(lǐng)域模型。這種領(lǐng)域模型在一個單純的技術(shù)實現(xiàn)層面來說，對于最簡單的業(yè)務(wù)，你可能只是Account類的增刪改查，但是對于復(fù)雜的業(yè)務(wù)來說，他就不單但是一個類，一個表的簡單操作了，例如開立賬戶，你要收手續(xù)費，以及考察個人財務(wù)狀況，那么此時你需要的就是一組協(xié)作的類。
Martin提到領(lǐng)域模型，意在強調(diào)我們應(yīng)該關(guān)注軟件的業(yè)務(wù)，關(guān)注行業(yè)知識的內(nèi)在規(guī)律，并且把這種規(guī)律建模為領(lǐng)域模型，批評拿到一個軟件，腦子里面光想到數(shù)據(jù)庫增刪改查的人。這和我們的Hibernate持久化類毫無關(guān)系！
我的看法是：一個抽象的領(lǐng)域模型具備多方面的特征，你需要用一組互相協(xié)作的類來完成它，每一個或者一組類承擔(dān)這個領(lǐng)域模型的某個特征。例如某個領(lǐng)域模型，例如上面的賬戶，你需要一組Hibernate持久化類：包括Account類，User類，F(xiàn)inance類，一組SpringBean類，AccountManager，F(xiàn)inanceManager，一組DAO接口和實現(xiàn)類。由這些POJO的類互相協(xié)作來共同完成這個領(lǐng)域模型。如果你僅僅關(guān)注Account的增刪改查，那就貧血了，而如果你關(guān)注了賬戶的業(yè)務(wù)規(guī)則，并且考慮一組互相協(xié)作的類去完成它，就不是貧血的。
竊以為，這是這段時間搜尋的領(lǐng)域模型概念的最合拍的解釋了。。
另外還有這兩篇
總結(jié)一下最近關(guān)于domain object以及相關(guān)的討論
再次小結(jié)領(lǐng)域模型的種種觀點
從技術(shù)手段來上說，對于Spring/Hibernate架構(gòu)，Martin的Rich domin model變得可行了，那么讓我們看看究竟有哪些領(lǐng)域模型，以及他們的優(yōu)缺點：
一、失血模型
失血模型請看
http://forum./viewtopic.php?t=11712
中列舉的第一種模型，簡單來說，就是domain object只有屬性的getter/setter方法，沒有任何業(yè)務(wù)邏輯。
二、貧血模型
貧血模型請看
http://forum./viewtopic.php?t=11712
中列舉的第二種模型，簡單來說，就是domain ojbect包含了不依賴于持久化的領(lǐng)域邏輯，而那些依賴持久化的領(lǐng)域邏輯被分離到Service層。
Service(業(yè)務(wù)邏輯，事務(wù)封裝) --> DAO ---> domain object
這種模型的優(yōu)點：
1、各層單向依賴，結(jié)構(gòu)清楚，易于實現(xiàn)和維護
2、設(shè)計簡單易行，底層模型非常穩(wěn)定
這種模型的缺點：
1、domain object的部分比較緊密依賴的持久化domain logic被分離到Service層，顯得不夠OO
2、Service層過于厚重
三、充血模型
充血模型和第二種模型差不多，所不同的就是如何劃分業(yè)務(wù)邏輯，即認(rèn)為，絕大多業(yè)務(wù)邏輯都應(yīng)該被放在domain object里面(包括持久化邏輯)，而Service層應(yīng)該是很薄的一層，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。
Service(事務(wù)封裝) ---> domain object <---> DAO
這種模型的優(yōu)點：
1、更加符合OO的原則
2、Service層很薄，只充當(dāng)Facade的角色，不和DAO打交道。
這種模型的缺點：
1、DAO和domain object形成了雙向依賴，復(fù)雜的雙向依賴會導(dǎo)致很多潛在的問題。
2、如何劃分Service層邏輯和domain層邏輯是非常含混的，在實際項目中，由于設(shè)計和開發(fā)人員的水平差異，可能導(dǎo)致整個結(jié)構(gòu)的混亂無序。
3、考慮到Service層的事務(wù)封裝特性，Service層必須對所有的domain object的邏輯提供相應(yīng)的事務(wù)封裝方法，其結(jié)果就是Service完全重定義一遍所有的domain logic，非常煩瑣，而且Service的事務(wù)化封裝其意義就等于把OO的domain logic轉(zhuǎn)換為過程的Service TransactionScript。該充血模型辛辛苦苦在domain層實現(xiàn)的OO在Service層又變成了過程式，對于Web層程序員的角度來看，和貧血模型沒有什么區(qū)別了。
四、脹血模型
基于充血模型的第三個缺點，有同學(xué)提出，干脆取消Service層，只剩下domain object和DAO兩層，在domain object的domain logic上面封裝事務(wù)。
domain object(事務(wù)封裝，業(yè)務(wù)邏輯) <---> DAO
似乎ruby on rails就是這種模型，他甚至把domain object和DAO都合并了。
該模型優(yōu)點：
1、簡化了分層
2、也算符合OO
該模型缺點：
1、很多不是domain logic的service邏輯也被強行放入domain object ，引起了domain ojbect模型的不穩(wěn)定
2、domain object暴露給web層過多的信息，可能引起意想不到的副作用。
在這四種模型當(dāng)中，失血模型和脹血模型應(yīng)該是不被提倡的。而貧血模型和充血模型從技術(shù)上來說，都已經(jīng)是可行的了。但是我個人仍然主張使用貧血模型。其理由：
1、參考充血模型第三個缺點，由于暴露給web層程序拿到的還是Service Transaction Script，對于web層程序員來說，底層OO意義喪失了。
2、參考充血模型第三個缺點，為了事務(wù)封裝，Service層要給每個domain logic提供一個過程化封裝，這對于編程來說，做了多余的工作，非常煩瑣。
3、domain object和DAO的雙向依賴在做大項目中，考慮到團隊成員的水平差異，很容易引入不可預(yù)知的潛在bug。
4、如何劃分domain logic和service logic的標(biāo)準(zhǔn)是不確定的，往往要根據(jù)個人經(jīng)驗，有些人就是覺得某個業(yè)務(wù)他更加貼近domain，也有人認(rèn)為這個業(yè)務(wù)是貼近service的。由于劃分標(biāo)準(zhǔn)的不確定性，帶來的后果就是實際項目中會產(chǎn)生很多這樣的爭議和糾紛，不同的人會有不同的劃分方法，最后就會造成整個項目的邏輯分層混亂。這不像貧血模型中我提出的按照是否依賴持久化進(jìn)行劃分，這種標(biāo)準(zhǔn)是非常確定的，不會引起爭議，因此團隊開發(fā)中，不會產(chǎn)生此類問題。
5、貧血模型的domain object確實不夠rich，但是我們是做項目，不是做研究，好用就行了，管它是不是那么純的OO呢？其實我不同意firebody認(rèn)為的貧血模型在設(shè)計模型和實現(xiàn)代碼中有很大跨越的說法。一個設(shè)計模型到實現(xiàn)的時候，你直接得到兩個類：一個實體類，一個控制類就行了，沒有什么跨越。
這邊提到ruby on rails，屬于脹血模型，因為它把domain object和DAO都合并了。
竊以為RoR是居于表模塊＋活動記錄，與JAVA適合的情況有些不同。采用活動記錄的架構(gòu)，在持久化的時候，語法貌似更OO些，是直接obj.save()這樣，而不是DAO,save(obj)
