這兩個概念是早些時候martin fowler總結出來的兩種常見模型設計型別，沒有說誰好誰不好，為不同的模型類別選擇合適的場景是設計者的工作。沒有工具本身的問題，只有工具使用者的問題。
貧血模型是指領域物件裡只有get和set方法（pojo），所有的業務邏輯都不包含在內而是放在business logic層。
優點是系統的層次結構清楚，各層之間單向依賴，client->（business facade）->business logic->data access object。可見，領域物件幾乎只作傳輸介質之用，不會影響到層次的劃分。
該模型的缺點是不夠物件導向，領域物件只是作為儲存狀態或者傳遞狀態使用，它是沒有生命的，只有資料沒有行為的物件不是真正的物件，在business logic裡面處理所有的業務邏輯，對於細粒度的邏輯處理，通過增加一層facade達到門面包裝的效果。
在使用spring的時候，通常暗示著你使用了貧血模型，我們把domain類用來單純地儲存資料，spring管不著這些類的注入和管理，spring關心的邏輯層（比如單例的被池化了的business logic層）可以被設計成singleton的bean。
假使我們這裡逆天而行，硬要在domain類中提供業務邏輯方法，那麼我們在使用spring構造這樣的資料bean的時候就遇到許多麻煩，比如：bean之間的引用，可能引起大範圍的bean之間的巢狀構造器的呼叫。
貧血模型實施的最大難度在於如何梳理好business logic層內部的劃分關係，由於該層會比較龐大，邊界不易控制，內部的各個模組之間的依賴關係不易管理，可以考慮這樣這樣的實現思路：
舉例說明：
原子業務邏輯層（service）提供了使用者模型的條件查詢方法：
listqueryuser(condition con)
facade層則提供了一種特定的業務場景的分子介面，滿足18歲的中國公民，內部實現呼叫的正是上述的原子介面：
listqueryadultchinese()
facade、service層縱向劃分為幾個大的領域包：使用者、內容和產品。
充血模型層次結構和上面的差不多，不過大多業務邏輯和持久化放在domain object裡面，business logic只是簡單封裝部分業務邏輯以及控制事務、許可權等，這樣層次結構就變成client->（business facade）->business logic->domain object->data access object。
它的優點是物件導向，business logic符合單一職責，不像在貧血模型裡面那樣包含所有的業務邏輯太過沉重。
缺點是如何劃分業務邏輯，什麼樣的邏輯應該放在domain object中，什麼樣的業務邏輯應該放在business logic中，這是很含糊的。即使劃分好了業務邏輯，由於分散在business logic和domain object層中，不能更好的分模組開發。熟悉業務邏輯的開發人員需要滲透到domain logic中去，而在domian logic又包含了持久化，對於開發者來說這十分混亂。 其次，如果business logic要控制事務並且為上層提供乙個統一的服務呼叫入口點，它就必須把在domain logic裡實現的業務邏輯全部重新包裝一遍，完全屬於重複勞動。
使用ror開發時， 每乙個領域模型物件都可以具備自己的基礎業務方法，通常滿足充血模型的特徵。充血模型更加適合較複雜業務邏輯的設計開發。
充血模型的層次和模組的劃分是一門學問，對開發人員要求亦較高，可以考慮定義這樣的一些規則：
萬事都不是絕對的，也有一些看起來不易解決的問題。例如，考慮到效能的需要，我需要一次查詢出滿足某種條件的使用者和某種條件的產品，他們二者之間通過訂購關係關聯起來，可能發現這種情形下，上述的模型層次劃分變得無解了……
貧血模型和充血模型
這兩個概念是早些時候martin fowler總結出來的兩種常見模型設計型別，沒有說誰好誰不好，為不同的模型類別選擇合適的場景是設計者的工作。沒有工具本身的問題，只有工具使用者的問題。貧血模型是指領域物件裡只有get和set方法 pojo 所有的業務邏輯都不包含在內而是放在business logi...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...