來源：juejin.cn/post/6917125801460629518
前言
要想深入掌握和了解 DDD 領域驅動設計的核心，那無論如何也繞不開兩大較為抽象的概念——“貧血模型”、“充血模型”：
- 貧血模型即事務腳本模式，
- 充血模型即領域模型模式，
貧血模型
貧血模型最早廣泛應用源于EJB2，最強盛時期則是由Spring創造，將：
- “行為”（邏輯、程序）；
- “狀態”（資料，對應到語言就是物件成員變數），
分離到不同的物件中：
- 只有狀態的物件就是所謂的“貧血物件”（常稱為VO——Value Object）；
- 只有行為的物件就是，我們常見的N層結構中的Logic/Service/Manager層（對應到EJB2中的Stateless Session Bean），
——曾經Spring的作者Rod Johnson也承認，Spring不過是在沿襲EJB2時代的“事務腳本”，也就是面向程序編程，
貧血領域模型是一個存在已久的反模式，目前仍有許多擁堆疊者，
Martin Fowler 曾經和 Eric Evans 聊天談到它時，都覺得這個模型似乎越來越流行了，作為領域模型的推廣者，他們覺得這不是一件好事，
貧血領域模型的基本特征是：它第一眼看起來還真像這么回事兒，專案中有許多物件，它們的命名都是根據領域來的，物件之間有著豐富的連接方式，和真正的領域模型非常相似，但當你檢視這些物件的行為時，會發現它們基本上沒有任何行為，僅僅是一堆getter/setter，
其實，這些物件在設計之初就被定義為只能包含資料，不能加入領域邏輯；邏輯要全部寫入一組叫Service的物件中；而Service則構建在領域模型之上，需要使用這些模型來傳遞資料，
這種反模式的恐怖之處在于：它完全和面向物件設計背道而馳，面向物件設計主張將資料和行為系結在一起，而貧血領域模型則更像是一種面向程序設計，Martin Fowler和Eric在Smalltalk時就極力反對這種做法，更糟糕的是，很多人認為這些貧血領域物件是真正的物件，從而徹底誤解了面向物件設計的涵義，
如今，面向物件的概念已經傳播得很廣泛了，而要反對這種貧血領域模型的做法，還需要更多論據，貧血領域模型的根本問題是，它引入了領域模型設計的所有成本，卻沒有帶來任何好處，最主要的成本是將物件映射到資料庫中，從而產生了一個O/R（物件關系）映射層，
只有當你充分使用了面向物件設計來組織復雜的業務邏輯后，這一成本才能夠被抵消，如果將所有行為都寫入到Service物件，那最終你會得到一組事務處理腳本，從而錯過了領域模型帶來的好處，正如martin在企業應用架構模式一書中說到的，領域模型并不一定是最好的工具，
將行為放入領域模型，這點和分層設計（領域層、持久化層、展現層等）并不沖突，因為領域模型中放入的是和領域相關的邏輯——驗證、計算、業務規則等，如果你要討論能否將資料源或展現邏輯放入到領域模型中，這就不在本文論述范圍之內了，
一些面向物件專家的觀點有時會讓人產生疑惑，他們認為的確應該有一個面向程序的服務層，但是，這并不意味著領域模型就不應該包含行為，事實上，service層需要和一組富含行為的領域模型結合使用，
Eric Evans的Domain Driven Design一書中提到：
應用層（即Service層）
描述應用程式所要做的作業，并調度豐富的領域模型來完成它，這個層次的任務是描述業務邏輯，或和其它專案的應用層做互動，這層很薄，不包含任何業務規則或知識，僅用于調度和派發任務給下一層的領域模型，這層沒有業務狀態，但可以為用戶或程式提供任務狀態，
領域層（或者叫模型層）
表示業務邏輯、業務場景和規則，該層次會控制和使用業務狀態，即使這些狀態最侄訓交由持久化層來存盤，總之，該層是軟體核心，
服務層很薄——所有重要的業務邏輯都寫在領域層，他在服務模式中復述了這一觀點：如今人們常犯的錯誤是不愿花時間將業務邏輯放到合適的領域模型中，從而逐漸形成面向程序的程式設計，
我不清楚為什么這種反模式會那么常見，我懷疑是因為大多數人并沒有使用過一個設計良好的領域模型，特別是那些以資料為中心的開發人員，此外，有些技術也會推動這種反模式，比如J2EE的Entity Bean，這會讓我更傾向于使用POJO領域模型，
總之，如果你將大部分行為都放置在服務層，那么你就會失去領域模型帶來的好處，如果你將所有行為都放在服務層，那你就無可救藥了，
優點
簡單：
- 對于只有少量業務邏輯的應用來說，使用起來非常自然；
- 開發迅速，易于理解；
- 注意：也不能完全排斥這種方式，
缺點
無法良好的應對復雜邏輯：
- 比如收入確認規則發生變化，例如在4月1號之前簽訂的合同要使用某規則……
- 和歐洲簽訂的合同使用另外一個規則……
充血模型
面向物件設計的本質是：“一個物件是擁有狀態和行為的”，
比如一個人：
- 他眼睛什么樣鼻子什么樣這就是狀態；
- 人可以去打游戲或是寫程式，這就是行為，
為什么要有一個“人Manager”這樣的東西存在去幫人“打游戲”呢？舉個簡單的J2EE案例，設計一個與用戶（User）相關功能，
傳統的設計一般是：
- 類：User+UserManager；
- 保存用戶呼叫：userManager.save(User user)，
充血的設計則可能會是：
- 類：User；
- 保存用戶呼叫：user.save()；
- User有一個行為是：保存它自己，
其實它們沒有什么特別適用的方向，個人更傾向于總是使用充血模型，因為OOP總是比面向程序編程要有更豐富的語意、更合理的組織、更強的可維護性—當然也更難掌握，
因此實際工程場景中，是否使用，如何使用還依賴于設計者以及團隊充血模型設計的理解和把握，因為現在絕大多數J2EE開發者都受貧血模型影響非常深，另外，實際工程場景中使用充血模型，還會碰到很多很多細節問題，其中最大的難關就是“如何設計充血模型”或者說“如何從復雜的業務中分離出恰到好處且包含語意的邏輯放到VO的行為中”，
如果一個物件包含其他物件，那就將職責繼續委托下去，由具體的 POJO 執行業務邏輯，將策略模式更加細粒度，而不是寫 ifelse，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/346851.html
標籤：Java