也就是說在領(lǐng)域模型中，本身只處理很少的行為邏輯，大多數(shù)都是處在模型上層的一系列的Service類來負(fù)責(zé)捕獲處理這些領(lǐng)域邏輯行為。這違背了OO思想（OO認(rèn)為應(yīng)該把數(shù)據(jù)和行為合在一起）。
Eric Evans在他的Domain Driven Design中說過：
Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.
據(jù)說在Thoughtwork公司里面采用的技術(shù)是Hibernate+Spring+webwork，關(guān)于anemia domain model有不少員工在公司內(nèi)部郵件中發(fā)問老馬應(yīng)該什么正確使用。但是老馬還沒有給出確切答案，只放入TODOList去。
我個人覺的Domail類中不應(yīng)該含有過多的與之無關(guān)的行為，不但違反了單一職責(zé)的原則，還使得整個系統(tǒng)不夠穩(wěn)定。例如User中有Roles，那么addRole,removeRole自然應(yīng)在Domain類User中寫，至于removeUser,loadUser等應(yīng)該封裝成Dao去處理。
引用robbin在一次討論中的回復(fù)：
我的理解是Martin大叔所謂的domain object是“領(lǐng)域模型”，它是一個針對業(yè)務(wù)邏輯抽象的模型，和軟件編程根本毫無關(guān)系。即使你不開發(fā)這個軟件，你仍然需要抽象你的業(yè)務(wù)邏輯得到你的領(lǐng)域模型。這個領(lǐng)域指的是你所從事的行業(yè)，而不是狹隘的持久化類。
并且領(lǐng)域模型的建模也是在需求分析階段，或者在需求分析階段之前完成的事情。具體到編程的過程中，領(lǐng)域模型并非對應(yīng)某一個Java類，如果一定要強(qiáng)行對應(yīng)的話，（業(yè)務(wù)對象，Dao接口，Hibernate實體類）他們合起來統(tǒng)稱領(lǐng)域模型在Java語言的實現(xiàn)。把 商業(yè)建模范疇的“領(lǐng)域模型”拿來當(dāng)做Hibernate編程中的實體類，根本就是牛頭不對馬嘴!
其實你的主張就是把持久化實體類的持久化操作附著到實體類上面去，而不是分開。舉例來說，也就是說Account類的增刪改查不應(yīng)該單獨(dú)分離到AccountDao接口去，而應(yīng)該把增刪改查操作放在Account類里面來完成，對不？
那么我在解釋這個問題之前，必須澄清一點(diǎn)，就是這個問題的討論，即持久化操作是否應(yīng)該單獨(dú)抽象一個DAO層的問題是和Martin Fowler提到了貧血的領(lǐng)域模型毫無關(guān)系的。實際上傳統(tǒng)的Entity Bean就是這種把持久化操作附著到Entity Bean本身去的，但是Martin Fowler一樣在說，這種Entity Bean就是貧血的。
好了，我們現(xiàn)在把其他無關(guān)因素排除了，focus到這個話題上，就是我們是否需要DAO接口的問題了。因為按照你的觀點(diǎn)，如果把對象的增刪改查都放在實體類上面，其實我們就不需要DAO接口層了，業(yè)務(wù)對象和Web Action都可以直接調(diào)用實體類本身來完成持久化操作了。
大概在2003年以前，我一直就是采用這種模型的，但是從2003年開始，我就改成了分離一個DAO層來專門處理持久化操作了。原因是多方面的，從技術(shù)角度來考量的話，分離就有很多好處，Rod Johnson在《without EJB》第10章持久化里面就詳細(xì)闡述了需要DAO層的理由，我建議你看一下，這里不復(fù)述了。只談一下除了Rod Johson提到理由之外的理由：
作為保持狀態(tài)的實體類，他的職責(zé)是保持狀態(tài)，而不負(fù)責(zé)狀態(tài)的持久化。如果把持久化操作也放在實體類中，一方面來說，把兩種不同的職責(zé)放在一個類中，并不符合OCP的單一職責(zé)的原則，然而更重要的原因是會帶來實體類的不穩(wěn)定的問題。
在我的理念中，實體類以及實體類關(guān)聯(lián)關(guān)系是一個軟件系統(tǒng)中最穩(wěn)定不變的部分，在整個軟件系統(tǒng)中，各個層面都需要涉及到實體類的操作，如何劃分實體類，以及確定實體類關(guān)聯(lián)是最費(fèi)考量的，確定了這一點(diǎn)，整個軟件系統(tǒng)就底層依賴關(guān)系就被確定下來了（實體類的屬性可以變化，由于軟件系統(tǒng)對實體的操作都是以實體類為單位的，所以實體屬性的變化不會造成系統(tǒng)不穩(wěn)定），上面的DAO層，業(yè)務(wù)層，Web層都只對實體類產(chǎn)生單向依賴。
如果你把DAO層合并到實體類中，請注意本來Web層是不依賴于DAO層的，Web層只依賴實體類（因為它要展現(xiàn)實體類狀態(tài)），但是由于你合并了，使得Web層也變得依賴那些DAO層的操作了。這樣的結(jié)果就是讓軟件系統(tǒng)的耦合性提高，可伸縮性降低，可維護(hù)性降低。
DAO層的變動是大于實體類變動的，實體類基本上穩(wěn)定不變，而軟件系統(tǒng)的需求變更幾乎一定會帶來DAO層的變動，但是并不會帶來實體類層的變動（會帶來實體屬性的變動，但是很少會影響到實體類本身）。所以DAO層的變動頻率遠(yuǎn)遠(yuǎn)大于實體類。那么當(dāng)你把DAO層操作合并到實體類以后，其結(jié)果就是讓實體類的變動頻率等于DAO層的變動頻率。那么就會造成本來穩(wěn)定的實體類層變得變得頻率高了很多，而實體類的變動會波及到軟件系統(tǒng)的每個層面，造成軟件大面積的相關(guān)性和不穩(wěn)定。
請記住很重要的一點(diǎn)：實體類是有狀態(tài)的類，DAO類是無狀態(tài)的類，在整個軟件系統(tǒng)中，只有兩種類有狀態(tài)，一個是實體類，一個是HTTP Session。有狀態(tài)的類會帶來很高的代碼相關(guān)性，應(yīng)該盡量減少有狀態(tài)類的影響范圍，盡量減少有狀態(tài)類的變動頻率，應(yīng)該盡量減少有狀態(tài)類的職責(zé)。
而你把DAO操作合并到實體類以后，結(jié)果就是擴(kuò)大了有狀態(tài)類的代碼相關(guān)性的范圍和影響范圍，擴(kuò)大了有狀態(tài)類的變動頻率，最后就造成軟件系統(tǒng)的穩(wěn)定性下降。