DDD 领域驱动设计：贫血模型、充血模型的深入解读
點擊上方“朱小廝的博客”，選擇“設為星標”
后臺回復"書"，獲取
后臺回復“k8s”，可領取k8s資料
-? ? ?前言? ? ?-
要想深入掌握和了解 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。
作者：JavaEdge在掘金
來源：juejin.cn/post/6917125801460629518
版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除并表示歉意。謝謝!
想知道更多？掃描下面的二維碼關注我
后臺回復"技術"，加入技術群
后臺回復“k8s”，可領取k8s資料
【精彩推薦】
ClickHouse到底是什么？為什么如此牛逼！
原來ElasticSearch還可以這么理解
面試官：InnoDB中一棵B+樹可以存放多少行數據？
架構之道：分離業務邏輯和技術細節
星巴克不使用兩階段提交
面試官：Redis新版本開始引入多線程，談談你的看法？
喜馬拉雅自研網關架構演進過程
收藏：存儲知識全面總結
微博千萬級規模高性能高并發的網絡架構設計
總結
以上是生活随笔為你收集整理的DDD 领域驱动设计：贫血模型、充血模型的深入解读的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 五分钟快速理解 Reactor 模型
- 下一篇： 漫画TCP——一个悲伤的故事