什么是充血模型？什么又是貧血模型?
貧血模型即事務(wù)腳本模式 充血模型即領(lǐng)域模型模式
貧血模型
最早廣泛應(yīng)用源于EJB2，最強盛時期則是由Spring創(chuàng)造，把
“行為”（邏輯、過程） “狀態(tài)”（數(shù)據(jù)，對應(yīng)到語言就是對象成員變量）
分離到不同的對象中：
只有狀態(tài)的對象就是所謂的“貧血對象”（常稱為VO——Value Object） 只有行為的對象就是我們常見的N層結(jié)構(gòu)中的Logic/Service/Manager層（對應(yīng)到EJB2中的Stateless Session Bean）。（曾經(jīng)Spring的作者Rod Johnson也承認，Spring不過是在沿襲EJB2時代的“事務(wù)腳本”，也就是面向過程編程）
貧血領(lǐng)域模型是一個存在已久的反模式，目前仍有許多擁躉者。Martin Fowler曾經(jīng)和Eric Evans聊天談到它時，都覺得這個模型似乎越來越流行了。作為領(lǐng)域模型的推廣者，他們覺得這不是一件好事。
貧血領(lǐng)域模型的基本特征是：它第一眼看起來還真像這么回事兒。項目中有許多對象，它們的命名都是根據(jù)領(lǐng)域來的。對象之間有著豐富的連接方式，和真正的領(lǐng)域模型非常相似。但當你檢視這些對象的行為時，會發(fā)現(xiàn)它們基本上沒有任何行為，僅僅是一堆getter/setter。其實這些對象在設(shè)計之初就被定義為只能包含數(shù)據(jù)，不能加入領(lǐng)域邏輯。這些邏輯要全部寫入一組叫Service的對象中。這些Service構(gòu)建在領(lǐng)域模型之上，使用這些模型來傳遞數(shù)據(jù)。
這種反模式的恐怖之處在于，它完全和面向?qū)ο笤O(shè)計背道而馳。面向?qū)ο笤O(shè)計主張將數(shù)據(jù)和行為綁定在一起，而貧血領(lǐng)域模型則更像是一種面向過程設(shè)計，Martin Fowler和Eric在Smalltalk時就極力反對這種做法。更糟糕的時，很多人認為這些貧血領(lǐng)域?qū)ο笫钦嬲膶ο螅瑥亩鴱氐渍`解了面向?qū)ο笤O(shè)計的涵義。
如今，面向?qū)ο蟮母拍钜呀?jīng)傳播得很廣泛了，而要反對這種貧血領(lǐng)域模型的做法，還需要更多論據(jù)。貧血領(lǐng)域模型的根本問題在于，它引入了領(lǐng)域模型設(shè)計的所有成本，卻沒有帶來任何好處。最主要的成本是將對象映射到數(shù)據(jù)庫中，從而產(chǎn)生了一個O/R（對象關(guān)系）映射層。只有當你充分使用了面向?qū)ο笤O(shè)計來組織復(fù)雜的業(yè)務(wù)邏輯后，這一成本才能夠被抵消。如果將所有行為都寫入到Service對象，那最終你會得到一組事務(wù)處理腳本，從而錯過了領(lǐng)域模型帶來的好處。正如martin在企業(yè)應(yīng)用架構(gòu)模式一書中說到的，領(lǐng)域模型并不一定是最好的工具。
將行為放入領(lǐng)域模型，這點和分層設(shè)計（領(lǐng)域?qū)印⒊志没瘜印⒄宫F(xiàn)層等）并不沖突。因為領(lǐng)域模型中放入的是和領(lǐng)域相關(guān)的邏輯——驗證、計算、業(yè)務(wù)規(guī)則等。如果你要討論能否將數(shù)據(jù)源或展現(xiàn)邏輯放入到領(lǐng)域模型中，這就不在本文論述范圍之內(nèi)了。
一些面向?qū)ο髮＜业挠^點有時會讓人產(chǎn)生疑惑，他們認為的確應(yīng)該有一個面向過程的服務(wù)層。但是，這并不意味著領(lǐng)域模型就不應(yīng)該包含行為。事實上，service層需要和一組富含行為的領(lǐng)域模型結(jié)合使用。
Eric Evans的Domain Driven Design一書中提到：
應(yīng)用層（即Service層）
描述應(yīng)用程序所要做的工作，并調(diào)度豐富的領(lǐng)域模型來完成它。這個層次的任務(wù)是描述業(yè)務(wù)邏輯，或和其它項目的應(yīng)用層做交互。這層很薄，不包含任何業(yè)務(wù)規(guī)則或知識，僅用于調(diào)度和派發(fā)任務(wù)給下一層的領(lǐng)域模型。這層沒有業(yè)務(wù)狀態(tài)，但可以為用戶或程序提供任務(wù)狀態(tài)。
領(lǐng)域?qū)樱ɑ蛘呓心Ｐ蛯樱?/section>
表示業(yè)務(wù)邏輯、業(yè)務(wù)場景和規(guī)則。該層次會控制和使用業(yè)務(wù)狀態(tài)，即使這些狀態(tài)最終會交由持久化層來存儲。總之，該層是軟件核心。
服務(wù)層很薄——所有重要的業(yè)務(wù)邏輯都寫在領(lǐng)域?qū)印Ｋ诜?wù)模式中復(fù)述了這一觀點：如今人們常犯的錯誤是不愿花時間將業(yè)務(wù)邏輯放到合適的領(lǐng)域模型中，從而逐漸形成面向過程的程序設(shè)計。
我不清楚為什么這種反模式會那么常見。我懷疑是因為大多數(shù)人并沒有使用過一個設(shè)計良好的領(lǐng)域模型，特別是那些以數(shù)據(jù)為中心的開發(fā)人員。此外，有些技術(shù)也會推動這種反模式，比如J2EE的Entity Bean，這會讓我更傾向于使用POJO領(lǐng)域模型。
總之，如果你將大部分行為都放置在服務(wù)層，那么你就會失去領(lǐng)域模型帶來的好處。如果你將所有行為都放在服務(wù)層，那你就無可救藥了。
優(yōu)點
簡單
對于只有少量業(yè)務(wù)邏輯的應(yīng)用來說，使用起來非常自然 開發(fā)迅速，易于理解 注意：也不能完全排斥這種方式
缺點
無法良好的應(yīng)對復(fù)雜邏輯
比如收入確認規(guī)則發(fā)生變化，例如在4月1號之前簽訂的合同要使用某規(guī)則..... 和歐洲簽訂的合同使用另外一個規(guī)則.....
充血模型
面向?qū)ο笤O(shè)計的本質(zhì)：“一個對象是擁有狀態(tài)和行為的”，比如一個人：
他眼睛什么樣鼻子什么樣這就是狀態(tài) 人可以去打游戲或是寫程序，這就是行為
為什么要有一個“人Manager”這樣的東西存在去幫人“打游戲”呢？舉個簡單的J2EE案例，設(shè)計一個與用戶（User）相關(guān)功能。傳統(tǒng)的設(shè)計一般是：
類：User+UserManager 保存用戶調(diào)用：userManager.save(User user)
充血的設(shè)計則可能會是：
類：User 保存用戶調(diào)用：user.save() User有一個行為是：保存它自己
其實它們沒有什么特別適用的方向，個人更傾向于總是使用充血模型，因為OOP總是比面向過程編程要有更豐富的語義、更合理的組織、更強的可維護性—當然也更難掌握。因此實際工程場景中，是否使用，如何使用還依賴于設(shè)計者以及團隊充血模型設(shè)計的理解和把握，因為現(xiàn)在絕大多數(shù)J2EE開發(fā)者都受貧血模型影響非常深。另外，實際工程場景中使用充血模型還會碰到很多很多細節(jié)問題，其中最大的難關(guān)就是“如何設(shè)計充血模型”或者說“如何從復(fù)雜的業(yè)務(wù)中分離出恰到好處且包含語義的邏輯放到VO的行為中”。
如果一個對象包含其他對象，那就將職責(zé)繼續(xù)委托下去，由具體的 POJO 執(zhí)行業(yè)務(wù)邏輯，將策略模式更加細粒度，而不是寫 ifelse。
往期推薦
免費領(lǐng)取：大佬設(shè)計模式學(xué)習(xí)筆記
喜歡的這里報道
↘↘↘