例子1、銀行帳號Account：
一個經常引起爭論的問題就是，deposit/draw方法到底應該建模到 Account中還是建模到AccountManager(對一個銀行出納員的建模)中。
我覺的將deposit/draw建模到AccountManger中是反映現實的，因為Account反映到現實世界就是一個沒有行為能力的實體，而出納員才具有行為能力。
例子2：選課的學生Student
對學生建模的時候，enroll(選課行為)毫無疑問應該建模到類Student中。
除此之外，我們假設每個學生有一個考察級點，可以根據這個學生的表現增加或者減少級點，而我們就遇到同例1中提到的deposit/draw一樣的問題，就是增加級點的方法addScore/減少級點的方法reduceScore建模到Student中還是StudentManager中，個人認為，同于例1，應該建模到StudentManager中而不是Student中。

總的來說，方法到底建模到那個Class中，就根據這個方法是否是這個Class自發的行為。譬如，Account的deposit/draw就不應該建模到Account中，但是實踐中，建模到Account中，往往會帶來一些好處，至于什么好處，Martin的《Domain Logic and SQL》非常全面的分析過了。所以，我感覺，Martin舉的例子中，貧血的Domain Model是亂扣大帽子。

本來就沒什么Transaction Script，沒什么貧血的Domain Model，Martin非要將一種正確的模型叫做“貧血的Domain Model"，而將沒有反映現實世界的、但是有一定實踐價值的模型起一個風度翩翩的名字。

為什么有人經常提到貧血的Domain Model？我覺的，可能很多應用是以數據為中心的，所以，建模的時候，習慣性地思維定向到數據上，建模出來的類完全是DB Entity的反映。而正確的思路，應該針對整個系統進行對象建模，不要一開始就考慮持久化的問題。

轉載于:https://www.cnblogs.com/wildfish/archive/2005/03/22/123788.html

總結

以上是生活随笔為你收集整理的贫血的Domain Model之说的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。