領域模型
領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型、領域物件模型、分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。
業務物件模型（也叫領域模型 domain model）是描述業務用例實現的物件模型。它是對業務角色和業務實體之間應該如何聯絡和協作以執行業務的一種抽象。業務物件模型從業務角色內部的觀點定義了業務用例。該模型為產生預期效果確定了業務人員以及他們處理和使用的物件（「業務類和物件」）之間應該具有的靜態和動態關係。它注重業務中承擔的角色及其當前職責。這些模型類的物件組合在一起可以執行所有的業務用例。
貧血模型是指領域物件裡只有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層內部的劃分關係，由於該層會比較龐大，邊界不易控制，內部的各個模組之間的依賴關係不易管理，可以考慮這樣這樣的實現思路：
（1）鋪設扁平的原子業務邏輯層，即簡單的crud操作（含批量資料操作）；
（2）特定業務清晰的邏輯通過facade層來組裝原子操作實現。
（3）給業務邏輯層實施模組劃分，保持模組之間的松耦合的關係。
舉例說明：
原子業務邏輯層（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開發時， 每乙個領域模型物件都可以具備自己的基礎業務方法，通常滿足充血模型的特徵。充血模型更加適合較複雜業務邏輯的設計開發。
充血模型的層次和模組的劃分是一門學問，對開發人員要求亦較高，可以考慮定義這樣的一些規則：
（1）事務控制不要放在領域模型的物件中實現，可以放在facade中完成。
（2）領域模型物件中只保留該模型驅動的一般方法，對於業務特徵明顯的特異場景方法呼叫放在facade中完成
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
貧血模型，充血模型 領域驅動設計
很多業務系統都是基於 mvc 三層架構來開發的。雖然這種開發模式已經成為標準的 web 專案的開發模式，但它卻違反了物件導向程式設計風格，是一種徹徹底底的面向過程的程式設計風格。mvc 三層架構中的 m 表示 model，v 表示 view，c 表示 controller 它將整個專案分為三層 展示...