最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把
分離到不同的物件中：
貧血領域模型是乙個存在已久的反模式，它不是個好東西。
它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。
貧血領域模型的根本問題在於，它引入了領域模型設計的所有成本，卻沒有帶來任何好處。
最主要的成本是將物件對映到資料庫中，從而產生了乙個o/r（物件關係）對映層。只有當你充分使用了物件導向設計來組織複雜的業務邏輯後，這一成本才能夠被抵消。如果將所有行為都寫入到service物件，那最終你會得到一組事務處理指令碼，從而錯過了領域模型帶來的好處。正如martin在企業應用架構模式一書中說到的，領域模型並不一定是最好的工具。
將行為放入領域模型，這點和分層設計（領域層、持久化層、展現層等）並不衝突。因為領域模型中放入的是和領域相關的邏輯——驗證、計算、業務規則等。如果你要討論能否將資料來源或展現邏輯放入到領域模型中，這就不在本文論述範圍之內了。
一些物件導向專家的觀點有時會讓人產生疑惑，他們認為的確應該有乙個面向過程的服務層。但是，這並不意味著領域模型就不應該包含行為。事實上，service層需要和一組富含行為的領域模型結合使用。
eric evans的domain driven design一書中提到：
服務層很薄——所有重要的業務邏輯都寫在領域層。他在服務模式中複述了這一觀點：
如今人們常犯的錯誤是不願花時間將業務邏輯放到合適的領域模型中，從而逐漸形成面向過程的程式設計。
為什麼這種反模式會那麼常見呢。我懷疑是因為大多數人並沒有使用過乙個設計良好的領域模型，特別是那些以資料為中心的開發人員。此外，有些技術也會推動這種反模式，比如j2ee的entity bean，這會讓我更傾向於使用pojo領域模型。
總之，如果你將大部分行為都放置在服務層，那麼你就會失去領域模型帶來的好處。如果你將所有行為都放在服務層，那你就無可救藥了。
簡單無法良好的應對複雜邏輯
物件導向設計的本質：「乙個物件是擁有狀態和行為的」，比如乙個人：
充血的設計則可能會是：
其實它們沒有什麼特別適用的方向，個人更傾向於總是使用充血模型，因為oop總是比面向過程程式設計要有更豐富的語義、更合理的組織、更強的可維護性—當然也更難掌握。因此實際工程場景中，是否使用，如何使用還依賴於設計者以及團隊充血模型設計的理解和把握，因為現在絕大多數j2ee開發者都受貧血模型影響非常深。另外，實際工程場景中使用充血模型還會碰到很多很多細節問題，其中最大的難關就是「如何設計充血模型」或者說「如何從複雜的業務中分離出恰到好處且包含語義的邏輯放到vo的行為中」。
如果乙個物件包含其他物件，那就將職責繼續委託下去，由具體的 pojo 執行業務邏輯，將策略模式更加細粒度，而不是寫 ifelse。
參考
貧血模型，充血模型 領域驅動設計
很多業務系統都是基於 mvc 三層架構來開發的。雖然這種開發模式已經成為標準的 web 專案的開發模式，但它卻違反了物件導向程式設計風格，是一種徹徹底底的面向過程的程式設計風格。mvc 三層架構中的 m 表示 model，v 表示 view，c 表示 controller 它將整個專案分為三層 展示...
DDD領域驅動設計和充血模型
什麼是貧血模型？貧血模型就是缺血了，缺東西，也就是只有資料但是沒有業務邏輯或者有業務邏輯但是沒有資料。比如你有乙個計算類，他有乙個加法計算的方法。但是他不持有計算的資料。和貧血模型對應的就是充血模型。什麼是充血模型？充血模型就是不缺血了，有資料同樣有業務邏輯。比如你的計算類現在不只有加法計算，還有需...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...