Martin Fowler很早以前就寫過一篇文章，題目叫"貧血模型"。文章裏面批判貧血的領域模型是不夠優雅、不夠OO的，提倡使用充血的領域模型。在Java世界裏這是一直爭論的話題。到底什麼是貧血什麼是充血呢？
貧血模型：是指領域對象裏只有get和set方法，或者包含少量的CRUD方法，所有的業務邏輯都不包含在內而是放在Business Logic層。
優點是系統的層次結構清楚，各層之間單向依賴，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。當然Business Logic是依賴Domain Object的。似乎現在流行的架構就是這樣，當然層次還可以細分。
該模型的缺點是不夠面向對象，領域對象只是作爲保存狀態或者傳遞狀態使用，所以就說只有數據沒有行爲的對象不是真正的對象。在Business Logic裏面處理所有的業務邏輯，在POEAA(企業應用架構模式)一書中被稱爲Transaction Script模式。
充血模型：層次結構和上面的差不多，不過大多業務邏輯和持久化放在Domain Object裏面，Business Logic只是簡單封裝部分業務邏輯以及控制事務、權限等，這樣層次結構就變成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
優點是面向對象，Business Logic符合單一職責，不像在貧血模型裏面那樣包含所有的業務邏輯太過沉重。
缺點是如何劃分業務邏輯，什麼樣的邏輯應該放在Domain Object中，什麼樣的業務邏輯應該放在Business Logic中，這是很含糊的。即使劃分好了業務邏輯，由於分散在Business Logic和Domain Object層中，不能更好的分模塊開發。熟悉業務邏輯的開發人員需要滲透到Domain Logic中去，而在Domian Logic又包含了持久化，對於開發者來說這十分混亂。 其次，因爲Business Logic要控制事務並且爲上層提供一個統一的服務調用入口點，它就必須把在Domain Logic裏實現的業務邏輯全部重新包裝一遍，完全屬於重複勞動。
如果技術能夠支持充血模型，那當然是最完美的解決方案。不過現在的.NET框架並沒有ORM工具（不算上開源的NHibernate，Castle之類），沒有ORM就沒有透明的持久化支持，在Domain Object層會對Data Access層構成依賴，如果脫離了Data Access層，Domain Object的業務邏輯就無法進行單元測試，這也是很致命的。如果有像Spring的動態注入和Hibernate的透明持久化支持，那麼充血模型還是能夠實現的。
作者：PEPE
出處：http://pepe.cnblogs.com/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利
自己的理解補充:
充血模型在Business Logic 業務邏輯層具有的優勢是更加面向對象,實現時只需調用對應的領域對象api即可,代碼設計更加內聚