DDD領域驅動設計?—?貧血模型與充血模型
[導讀]文章轉載來源：https://juejin.cn/post/6917125801460629518|前言?要想深入掌握和了解DDD領域驅動設計的核心，那無論如何也繞不開兩大較為抽象的概念——“貧血模型”、“充血模型”：貧血模型即事務腳本模式。充血模型即領域模型模式。|貧血模型貧血...
文章轉載來源：https://juejin.cn/post/6917125801460629518| 前言?要想深入掌握和了解 DDD 領域驅動設計的核心，那無論如何也繞不開兩大較為抽象的概念——“貧血模型”、“充血模型”：
貧血領域模型的基本特征是：它第一眼看起來還真像這么回事兒。項目中有許多對象，它們的命名都是根據領域來的。對象之間有著豐富的連接方式，和真正的領域模型非常相似。但當你檢視這些對象的行為時，會發(fā)現(xiàn)它們基本上沒有任何行為，僅僅是一堆getter/setter。其實，這些對象在設計之初就被定義為只能包含數(shù)據，不能加入領域邏輯；邏輯要全部寫入一組叫Service的對象中；而Service則構建在領域模型之上，需要使用這些模型來傳遞數(shù)據。這種反模式的恐怖之處在于：它完全和面向對象設計背道而馳。面向對象設計主張將數(shù)據和行為綁定在一起，而貧血領域模型則更像是一種面向過程設計，Martin Fowler和Eric在Smalltalk時就極力反對這種做法。更糟糕的是，很多人認為這些貧血領域對象是真正的對象，從而徹底誤解了面向對象設計的涵義。如今，面向對象的概念已經傳播得很廣泛了，而要反對這種貧血領域模型的做法，還需要更多論據。貧血領域模型的根本問題是，它引入了領域模型設計的所有成本，卻沒有帶來任何好處。最主要的成本是將對象映射到數(shù)據庫中，從而產生了一個O/R（對象關系）映射層。只有當你充分使用了面向對象設計來組織復雜的業(yè)務邏輯后，這一成本才能夠被抵消。如果將所有行為都寫入到Service對象，那最終你會得到一組事務處理腳本，從而錯過了領域模型帶來的好處。正如martin在企業(yè)應用架構模式一書中說到的，領域模型并不一定是最好的工具。將行為放入領域模型，這點和分層設計（領域層、持久化層、展現(xiàn)層等）并不沖突。因為領域模型中放入的是和領域相關的邏輯——驗證、計算、業(yè)務規(guī)則等。如果你要討論能否將數(shù)據源或展現(xiàn)邏輯放入到領域模型中，這就不在本文論述范圍之內了。一些面向對象專家的觀點有時會讓人產生疑惑，他們認為的確應該有一個面向過程的服務層。但是，這并不意味著領域模型就不應該包含行為。事實上，service層需要和一組富含行為的領域模型結合使用。Eric Evans的Domain Driven Design一書中提到：應用層（即Service層）描述應用程序所要做的工作，并調度豐富的領域模型來完成它。這個層次的任務是描述業(yè)務邏輯，或和其它項目的應用層做交互。這層很薄，不包含任何業(yè)務規(guī)則或知識，僅用于調度和派發(fā)任務給下一層的領域模型。這層沒有業(yè)務狀態(tài)，但可以為用戶或程序提供任務狀態(tài)。領域層（或者叫模型層）表示業(yè)務邏輯、業(yè)務場景和規(guī)則。該層次會控制和使用業(yè)務狀態(tài)，即使這些狀態(tài)最終會交由持久化層來存儲?？傊?，該層是軟件核心。服務層很薄——所有重要的業(yè)務邏輯都寫在領域層。他在服務模式中復述了這一觀點：如今人們常犯的錯誤是不愿花時間將業(yè)務邏輯放到合適的領域模型中，從而逐漸形成面向過程的程序設計。我不清楚為什么這種反模式會那么常見。我懷疑是因為大多數(shù)人并沒有使用過一個設計良好的領域模型，特別是那些以數(shù)據為中心的開發(fā)人員。此外，有些技術也會推動這種反模式，比如J2EE的Entity Bean，這會讓我更傾向于使用POJO領域模型。總之，如果你將大部分行為都放置在服務層，那么你就會失去領域模型帶來的好處。如果你將所有行為都放在服務層，那你就無可救藥了。
- 貧血模型即事務腳本模式。
- 充血模型即領域模型模式。
- “行為”（邏輯、過程）；
- “狀態(tài)”（數(shù)據，對應到語言就是對象成員變量）。
- 只有狀態(tài)的對象就是所謂的“貧血對象”（常稱為VO——Value Object）；
- 只有行為的對象就是，我們常見的N層結構中的Logic/Service/Manager層（對應到EJB2中的Stateless Session Bean）。
貧血領域模型的基本特征是：它第一眼看起來還真像這么回事兒。項目中有許多對象，它們的命名都是根據領域來的。對象之間有著豐富的連接方式，和真正的領域模型非常相似。但當你檢視這些對象的行為時，會發(fā)現(xiàn)它們基本上沒有任何行為，僅僅是一堆getter/setter。其實，這些對象在設計之初就被定義為只能包含數(shù)據，不能加入領域邏輯；邏輯要全部寫入一組叫Service的對象中；而Service則構建在領域模型之上，需要使用這些模型來傳遞數(shù)據。這種反模式的恐怖之處在于：它完全和面向對象設計背道而馳。面向對象設計主張將數(shù)據和行為綁定在一起，而貧血領域模型則更像是一種面向過程設計，Martin Fowler和Eric在Smalltalk時就極力反對這種做法。更糟糕的是，很多人認為這些貧血領域對象是真正的對象，從而徹底誤解了面向對象設計的涵義。如今，面向對象的概念已經傳播得很廣泛了，而要反對這種貧血領域模型的做法，還需要更多論據。貧血領域模型的根本問題是，它引入了領域模型設計的所有成本，卻沒有帶來任何好處。最主要的成本是將對象映射到數(shù)據庫中，從而產生了一個O/R（對象關系）映射層。只有當你充分使用了面向對象設計來組織復雜的業(yè)務邏輯后，這一成本才能夠被抵消。如果將所有行為都寫入到Service對象，那最終你會得到一組事務處理腳本，從而錯過了領域模型帶來的好處。正如martin在企業(yè)應用架構模式一書中說到的，領域模型并不一定是最好的工具。將行為放入領域模型，這點和分層設計（領域層、持久化層、展現(xiàn)層等）并不沖突。因為領域模型中放入的是和領域相關的邏輯——驗證、計算、業(yè)務規(guī)則等。如果你要討論能否將數(shù)據源或展現(xiàn)邏輯放入到領域模型中，這就不在本文論述范圍之內了。一些面向對象專家的觀點有時會讓人產生疑惑，他們認為的確應該有一個面向過程的服務層。但是，這并不意味著領域模型就不應該包含行為。事實上，service層需要和一組富含行為的領域模型結合使用。Eric Evans的Domain Driven Design一書中提到：應用層（即Service層）描述應用程序所要做的工作，并調度豐富的領域模型來完成它。這個層次的任務是描述業(yè)務邏輯，或和其它項目的應用層做交互。這層很薄，不包含任何業(yè)務規(guī)則或知識，僅用于調度和派發(fā)任務給下一層的領域模型。這層沒有業(yè)務狀態(tài)，但可以為用戶或程序提供任務狀態(tài)。領域層（或者叫模型層）表示業(yè)務邏輯、業(yè)務場景和規(guī)則。該層次會控制和使用業(yè)務狀態(tài)，即使這些狀態(tài)最終會交由持久化層來存儲?？傊?，該層是軟件核心。服務層很薄——所有重要的業(yè)務邏輯都寫在領域層。他在服務模式中復述了這一觀點：如今人們常犯的錯誤是不愿花時間將業(yè)務邏輯放到合適的領域模型中，從而逐漸形成面向過程的程序設計。我不清楚為什么這種反模式會那么常見。我懷疑是因為大多數(shù)人并沒有使用過一個設計良好的領域模型，特別是那些以數(shù)據為中心的開發(fā)人員。此外，有些技術也會推動這種反模式，比如J2EE的Entity Bean，這會讓我更傾向于使用POJO領域模型。總之，如果你將大部分行為都放置在服務層，那么你就會失去領域模型帶來的好處。如果你將所有行為都放在服務層，那你就無可救藥了。
優(yōu)點
簡單：- 對于只有少量業(yè)務邏輯的應用來說，使用起來非常自然；
- 開發(fā)迅速，易于理解；
- 注意：也不能完全排斥這種方式。
缺點
無法良好的應對復雜邏輯：- 比如收入確認規(guī)則發(fā)生變化，例如在4月1號之前簽訂的合同要使用某規(guī)則……
- 和歐洲簽訂的合同使用另外一個規(guī)則……
- 他眼睛什么樣鼻子什么樣這就是狀態(tài)；
- 人可以去打游戲或是寫程序，這就是行為。
- 類：User UserManager；
- 保存用戶調用：userManager.save(User user)。
- 類：User；
- 保存用戶調用：user.save()；
- User有一個行為是：保存它自己。
- 《領域驅動設計》
- www.zhihu.com/question/20360521/answer/14891150
- www.martinfowler.com/bliki/AnemicDomainModel.html
下載文檔本站聲明： 本文章由作者或相關機構授權發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點，本站亦不保證或承諾內容真實性等。需要轉載請聯(lián)系該專欄作者，如若文章內容侵犯您的權益，請及時聯(lián)系本站刪除。
換一批
延伸閱讀
來見識下這位95后的手工大神。據媒體報道，山東青島一女生耗時一個月，使用10斤巧克力，復刻了《武林外傳》里的小院，堪稱神還原。女孩介紹，大大小小的物件超過200件，每一個小物件都是用巧克力、翻糖和糯米紙做的，模型長度大概...
關鍵字： 模型
