關於領域模型的設計問題，JavaEye已經組織過n多次大規模討論，幾乎每過一段時期就會出現一次。最近出現了一個新的趨勢，Craig Walls在自己的blog上面寫一篇文章，介紹如何使用Spring2.0和AspectJ的新特性給domain object注入DAO依賴，即如何實現post-instantiation，請見：
http://jroller.com/page/habuma?entry=spring_2_0_vs_the
與此同時，ajoo也給出了nuts的post-instantiation方案，請見：
http://www.javaeye.com/display/ajoo/Dependency+Injection+For+Rich+Domain+Model
因此，從技術手段來上說，對於Spring/Hibernate架構，Martin的Rich domin model變得可行了，那麼讓我們看看究竟有哪些領域模型，以及他們的優缺點：
一、失血模型
失血模型請看
http://forum.javaeye.com/viewtopic.php?t=11712
中列舉的第一種模型，簡單來說，就是domain object只有屬性的getter/setter方法，沒有任何業務邏輯。
二、貧血模型
貧血模型請看
http://forum.javaeye.com/viewtopic.php?t=11712
中列舉的第二種模型，簡單來說，就是domain ojbect包含了不依賴於持久化的領域邏輯，而那些依賴持久化的領域邏輯被分離到Service層。
Service(業務邏輯，事務封裝) --> DAO ---> domain object
這種模型的優點：
1、各層單向依賴，結構清楚，易於實現和維護
2、設計簡單易行，底層模型非常穩定
這種模型的缺點：
1、domain object的部分比較緊密依賴的持久化domain logic被分離到Service層，顯得不夠OO
2、Service層過於厚重
三、充血模型
充血模型和第二種模型差不多，所不同的就是如何劃分業務邏輯，即認爲，絕大多業務邏輯都應該被放在domain object裏面(包括持久化邏輯)，而Service層應該是很薄的一層，僅僅封裝事務和少量邏輯，不和DAO層打交道。
Service(事務封裝) ---> domain object <---> DAO
這種模型的優點：
1、更加符合OO的原則
2、Service層很薄，只充當Facade的角色，不和DAO打交道。
這種模型的缺點：
1、DAO和domain object形成了雙向依賴，複雜的雙向依賴會導致很多潛在的問題。
2、如何劃分Service層邏輯和domain層邏輯是非常含混的，在實際項目中，由於設計和開發人員的水平差異，可能導致整個結構的混亂無序。
3、考慮到Service層的事務封裝特性，Service層必須對所有的domain object的邏輯提供相應的事務封裝方法，其結果就是Service完全重定義一遍所有的domain logic，非常煩瑣，而且Service的事務化封裝其意義就等於把OO的domain logic轉換爲過程的Service TransactionScript。該充血模型辛辛苦苦在domain層實現的OO在Service層又變成了過程式，對於Web層程序員的角度來看，和貧血模型沒有什麼區別了。
四、脹血模型
基於充血模型的第三個缺點，有同學提出，乾脆取消Service層，只剩下domain object和DAO兩層，在domain object的domain logic上面封裝事務。
domain object(事務封裝，業務邏輯) <---> DAO
似乎ruby on rails就是這種模型，他甚至把domain object和DAO都合併了。
該模型優點：
1、簡化了分層
2、也算符合OO
該模型缺點：
1、很多不是domain logic的service邏輯也被強行放入domain object ，引起了domain ojbect模型的不穩定
2、domain object暴露給web層過多的信息，可能引起意想不到的副作用。
在這四種模型當中，失血模型和脹血模型應該是不被提倡的。而貧血模型和充血模型從技術上來說，都已經是可行的了。但是我個人仍然主張使用貧血模型。其理由：
1、參考充血模型第三個缺點，由於暴露給web層程序拿到的還是Service Transaction Script，對於web層程序員來說，底層OO意義喪失了。
2、參考充血模型第三個缺點，爲了事務封裝，Service層要給每個domain logic提供一個過程化封裝，這對於編程來說，做了多餘的工作，非常煩瑣。
3、domain object和DAO的雙向依賴在做大項目中，考慮到團隊成員的水平差異，很容易引入不可預知的潛在bug。
4、如何劃分domain logic和service logic的標準是不確定的，往往要根據個人經驗，有些人就是覺得某個業務他更加貼近domain，也有人認爲這個業務是貼近service的。由於劃分標準的不確定性，帶來的後果就是實際項目中會產生很多這樣的爭議和糾紛，不同的人會有不同的劃分方法，最後就會造成整個項目的邏輯分層混亂。這不像貧血模型中我提出的按照是否依賴持久化進行劃分，這種標準是非常確定的，不會引起爭議，因此團隊開發中，不會產生此類問題。
5、貧血模型的domain object確實不夠rich，但是我們是做項目，不是做研究，好用就行了，管它是不是那麼純的OO呢？其實我不同意firebody認爲的貧血模型在設計模型和實現代碼中有很大跨越的說法。一個設計模型到實現的時候，你直接得到兩個類：一個實體類，一個控制類就行了，沒有什麼跨越。
關於領域模型的問題，限於時間原因，暫時不能展開詳談，待有空，寫篇更加詳細的文章。
