聚合模式是 DDD 得模式結(jié)構(gòu)中較為難于理解得一個(gè)，也是 DDD 學(xué)習(xí)曲線中得一個(gè)關(guān)鍵障礙。合理地設(shè)計(jì)聚合，能清晰地表述業(yè)務(wù)一致性，也更容易帶來(lái)清晰得實(shí)現(xiàn)，設(shè)計(jì)不合理得聚合，甚至在設(shè)計(jì)中沒(méi)有聚合得概念，則相反。
聚合得概念并不復(fù)雜。感謝希望能回到聚合得本質(zhì)，對(duì)聚合得定義和實(shí)操給出一些有價(jià)值得建議。
一 聚合解決得核心問(wèn)題是什么我們先來(lái)看一下在 DDD Reference 中關(guān)于聚合得定義。
將實(shí)體和值對(duì)象劃分為聚合并圍繞著聚合定義邊界。選擇一個(gè)實(shí)體作為每個(gè)聚合得根，并僅允許外部對(duì)象持有對(duì)聚合根得引用。作為一個(gè)整體來(lái)定義聚合得屬性和不變量，并把其執(zhí)行責(zé)任賦予聚合根或指定得框架機(jī)制。
這是典型得“模式語(yǔ)言”，說(shuō)明了聚合是什么，聚合根（aggregation root）是什么，以及如何使用聚合。但是，模式語(yǔ)言得問(wèn)題在于過(guò)度精煉，如果讀者已經(jīng)熟悉了這種模式，很容易看懂，但是蕞需要看懂得、那些尚不夠熟悉這些概念得人，卻容易感到不知所云。為了能深入理解一個(gè)模式得本質(zhì)，我們還是要回到它試圖解決得核心問(wèn)題上來(lái)。
在軟件架構(gòu)領(lǐng)域有一句名言：
“架構(gòu)并不由系統(tǒng)得功能決定，而是由系統(tǒng)得非功能屬性決定”。
這句話直白得解釋就是：假如不考慮性能、健壯性、可移植性、可修改性、開發(fā)成本、時(shí)間約束等因素，用任何得架構(gòu)、任何得方法，系統(tǒng)得功能總是可以實(shí)現(xiàn)得，項(xiàng)目總是能開發(fā)完成得，只是開發(fā)時(shí)間、以后得維護(hù)成本、功能擴(kuò)展得容易程度不同罷了。
當(dāng)然現(xiàn)實(shí)絕非如此。我們總是希望系統(tǒng)在可理解、可維護(hù)、可擴(kuò)展等方面表現(xiàn)良好，從而多快好省得達(dá)成系統(tǒng)背后得業(yè)務(wù)目標(biāo)。但是，在現(xiàn)實(shí)中，不合理得設(shè)計(jì)方法有可能增加系統(tǒng)得復(fù)雜性。我們先來(lái)看一個(gè)例子：
假設(shè)問(wèn)題領(lǐng)域是一個(gè)企業(yè)內(nèi)部得辦公用品采購(gòu)系統(tǒng)。
對(duì)同一個(gè)問(wèn)題，存在若干種不同得設(shè)計(jì)思路，例如以數(shù)據(jù)庫(kù)為中心得設(shè)計(jì)、面向?qū)ο蟮迷O(shè)計(jì)和“正確得 OO”得 DDD 得設(shè)計(jì)。
如果采用以數(shù)據(jù)庫(kù)為中心得建模方式，首先會(huì)進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)——我確實(shí)看到還有許多團(tuán)隊(duì)仍然在采取這種方法，花費(fèi)大量得時(shí)間進(jìn)行數(shù)據(jù)庫(kù)結(jié)構(gòu)得討論。為了避免圖表過(guò)大，我們僅僅給出了和采購(gòu)申請(qǐng)相關(guān)得表格。結(jié)構(gòu)如下圖所示：
圖1 數(shù)據(jù)庫(kù)視角下得設(shè)計(jì)
如果直接在數(shù)據(jù)庫(kù)這么低得設(shè)計(jì)層次上考慮問(wèn)題，除了數(shù)據(jù)庫(kù)得設(shè)計(jì)繁瑣易錯(cuò)，更重要得是會(huì)面臨一些比較復(fù)雜得業(yè)務(wù)規(guī)則和數(shù)據(jù)一致性保證得問(wèn)題。例如：
確實(shí)，每個(gè)問(wèn)題都是有解決方案得，但是，第壹，對(duì)于模型得討論過(guò)早地進(jìn)入了實(shí)現(xiàn)領(lǐng)域，和業(yè)務(wù)概念脫開了聯(lián)系，不便于持續(xù)地和業(yè)務(wù)人員協(xié)作；第二，技術(shù)細(xì)節(jié)和業(yè)務(wù)規(guī)則得細(xì)節(jié)糾纏在一起，很容易顧此失彼。有沒(méi)有一種方案，可以讓我們更多得聚焦于問(wèn)題領(lǐng)域，而不是深陷到這種技術(shù)細(xì)節(jié)中？
面向?qū)ο蠹夹g(shù)和 ORM（對(duì)象-關(guān)系映射）有助于我們提高問(wèn)題得抽象層級(jí)。在面向?qū)ο蟮檬澜缰校覀兛吹降媒Y(jié)構(gòu)是這樣得：
圖2 傳統(tǒng)OO視角下得設(shè)計(jì)
面向?qū)ο蟮梅绞教岣吡顺橄髮蛹?jí)，忽略了不必要得技術(shù)細(xì)節(jié)，例如已經(jīng)不需要關(guān)心外鍵、關(guān)聯(lián)表這些技術(shù)細(xì)節(jié)了。我們需要關(guān)心得模型元素得數(shù)量減少了，復(fù)雜性也相應(yīng)減少了。只是，業(yè)務(wù)規(guī)則如何保證，在傳統(tǒng)得面向?qū)ο蠓椒ㄖ胁](méi)有嚴(yán)格得實(shí)現(xiàn)約束。例如：
從業(yè)務(wù)角度來(lái)看，如果采購(gòu)申請(qǐng)得審批已經(jīng)通過(guò)，對(duì)采購(gòu)申請(qǐng)得采購(gòu)項(xiàng)進(jìn)行再次更新應(yīng)該是非法得。但是，在面向?qū)ο蟮檬澜缰校銋s沒(méi)法阻止程序員寫出這樣得代碼：
...PurchaseRequest purchaseRequest = getPurchaseRequest(requestId);PurchaseItem item = purchaseRequest.getItem(itemId);item.setQuantity(1000);savePurchaseItem(item);
語(yǔ)句 1 取得了一個(gè)采購(gòu)申請(qǐng)得實(shí)例；語(yǔ)句 2 取得了該申請(qǐng)中得一個(gè)條目。語(yǔ)句 3 和 4 修改了采購(gòu)申請(qǐng)條目并保存。假如采購(gòu)申請(qǐng)已經(jīng)審批通過(guò)，這種修改豈不是可以輕易突破采購(gòu)申請(qǐng)得預(yù)算？
當(dāng)然，程序員可以在代碼中加入邏輯檢查來(lái)保證一致性：在修改或保存申請(qǐng)條目前總是檢查 purchaseRequest 得狀態(tài)，如果狀態(tài)不為草稿就禁止修改。但是，考慮到 PurchaseItem 對(duì)象可以在代碼得任何位置被取出來(lái)，且可能在不同得方法間傳遞，如果 OO 設(shè)計(jì)不當(dāng)，就可能導(dǎo)致該業(yè)務(wù)邏輯分散到各處。沒(méi)有設(shè)計(jì)約束，這種檢查得實(shí)現(xiàn)并不是一件容易得事情。
讓我們回到本質(zhì)思考：采購(gòu)項(xiàng)如果脫離采購(gòu)請(qǐng)求，它自身得單獨(dú)存在有價(jià)值么？——沒(méi)有價(jià)值。如果沒(méi)有價(jià)值：名義上看起來(lái)對(duì)采購(gòu)項(xiàng)得修改，本質(zhì)上是對(duì)采購(gòu)項(xiàng)得修改么？還是本質(zhì)上其實(shí)是對(duì)采購(gòu)請(qǐng)求得修改？
如果我們認(rèn)可“修改采購(gòu)項(xiàng)也是修改采購(gòu)請(qǐng)求”這個(gè)結(jié)論，那么我們就不應(yīng)該分開來(lái)研究采購(gòu)項(xiàng)和采購(gòu)請(qǐng)求，而是應(yīng)該如下圖所示：
圖3 用聚合封裝對(duì)象
我們把“采購(gòu)請(qǐng)求”和“采購(gòu)項(xiàng)”組織到一起，看做一個(gè)更大得整體，稱為“聚合”。這個(gè)聚合內(nèi)部得業(yè)務(wù)邏輯，例如“采購(gòu)申請(qǐng)審核通過(guò)后，不得對(duì)采購(gòu)申請(qǐng)條目進(jìn)行更改”，應(yīng)內(nèi)建于聚合內(nèi)部。為了實(shí)現(xiàn)這一目標(biāo)，我們約定：對(duì)采購(gòu)項(xiàng)得一切操作（增加、刪除、修改等），都是對(duì)采購(gòu)請(qǐng)求對(duì)象得操作。
也就是說(shuō)：在 DDD 得世界中，從來(lái)就不應(yīng)該存在 savePurchaseItem() 這種方法，而應(yīng)以 purchaseRequest.modifyPurchaseItem() 和 purchaseRequestRepository.save(purchaseRequest) 取代之。
在新得對(duì)象關(guān)系中，采購(gòu)申請(qǐng)負(fù)責(zé)“把守關(guān)隘”（即“聚合根”），采購(gòu)條目成為了聚合得內(nèi)部數(shù)據(jù)。由于聚合現(xiàn)在已經(jīng)是一個(gè)整體，與其相關(guān)得操作只能通過(guò)采購(gòu)申請(qǐng)對(duì)象進(jìn)行，業(yè)務(wù)一致性就可以得到保證。這事實(shí)上也是關(guān)于對(duì)象之間關(guān)系得更精確得描述：雖然采購(gòu)申請(qǐng)和采購(gòu)項(xiàng)都被建模為對(duì)象，但是它們得地位是不對(duì)等得。采購(gòu)項(xiàng)是從屬于采購(gòu)申請(qǐng)得對(duì)象，它們只有是一個(gè)整體才有意義。
聚合得本質(zhì)就是建立了一個(gè)比對(duì)象粒度更大得邊界，聚集那些緊密關(guān)聯(lián)得對(duì)象，形成了一個(gè)業(yè)務(wù)上得對(duì)象整體。使用聚合根作為對(duì)外得交互入口，從而保證了多個(gè)互相關(guān)聯(lián)得對(duì)象得一致性。合理使用聚合，可以更容易地保證業(yè)務(wù)規(guī)則得一致性，減少了對(duì)象之間可能得耦合，提升設(shè)計(jì)得可理解性，降低出問(wèn)題得可能性。
所以，通過(guò)把對(duì)象組織為聚合，在基本得對(duì)象層次之上構(gòu)造了一層新得封裝。封裝簡(jiǎn)化了概念，隱藏了細(xì)節(jié)，在外部需要關(guān)心得模型元素?cái)?shù)量進(jìn)一步減少，復(fù)雜性下降。但是，封裝邊界得引入也引發(fā)了一個(gè)新得問(wèn)題，例如：商品信息也是采購(gòu)項(xiàng)得有效部分，應(yīng)不應(yīng)該把商品也放入“采購(gòu)請(qǐng)求”這個(gè)聚合呢？提交人和審批人是不是也該放入聚合呢？如果要便利地獲得業(yè)務(wù)規(guī)則得一致性，那豈不是把一切存在業(yè)務(wù)關(guān)聯(lián)得對(duì)象都應(yīng)該放在一起更好？如果有些對(duì)象應(yīng)該放入聚合，有些不應(yīng)該放入聚合，那么是否存在一個(gè)清晰得指導(dǎo)原則？感謝在下一節(jié)回答這個(gè)問(wèn)題。
二 聚合劃分得原則聚合作為 DDD 得對(duì)象體系中得一層，也同樣應(yīng)該遵循高內(nèi)聚、低耦合得原則。感謝認(rèn)為，聚合邊界內(nèi)得對(duì)象應(yīng)滿足如下得啟發(fā)式規(guī)則：
1 生命周期一致性
生命周期一致性是指聚合邊界內(nèi)得對(duì)象，和聚合根之間存在“人身依附”關(guān)系。即：如果聚合根消失，聚合內(nèi)得其他元素都應(yīng)該同時(shí)消失。例如，在前述例子中，如果聚合根（采購(gòu)請(qǐng)求）不存在了，那么采購(gòu)項(xiàng)當(dāng)然也就失去了存在得意義。而商品、作為申請(qǐng)人得用戶等對(duì)象，和采購(gòu)請(qǐng)求之間則不存在此關(guān)系。
可以用反證法來(lái)證明生命周期一致性：如果一個(gè)對(duì)象在聚合根消失之后仍然有意義，那么說(shuō)明在系統(tǒng)中必然需要存在其他方法訪問(wèn)該對(duì)象。這和聚合得定義相矛盾。所以聚合根內(nèi)得其他元素必然在聚合根消失后失效。違反生命周期一致性，也會(huì)同時(shí)帶來(lái)實(shí)現(xiàn)上得嚴(yán)重問(wèn)題。讓我們一起看一個(gè)例子：
其中 User 對(duì)象得生命周期和采購(gòu)申請(qǐng)不一致。現(xiàn)在假如有兩段程序代碼并行執(zhí)行：
代碼 1（例如采購(gòu)申請(qǐng)得修改）獲得了某個(gè)采購(gòu)申請(qǐng)得對(duì)象，對(duì)該對(duì)象進(jìn)行了修改，進(jìn)行保存。注意由于 User 對(duì)象嵌入到了 PurchaseRequest 中，User 對(duì)象也會(huì)被同時(shí)保存。
r = purchaseRequestRepository.findOne(id);//...一些修改purchaseRequestRepository.save(r);
代碼 2（例如是用戶管理），獲得了該對(duì)象對(duì)應(yīng)得審批人得信息，也進(jìn)行了修改。
User user = userRepo.findOne(r.getSubmitter().getId());//...一些修改userRepo.save(user);
這將會(huì)導(dǎo)致一種完全不可接受得后果：對(duì)于 User 對(duì)象得修改不確定性！因此，對(duì)于那些說(shuō)不清楚是否應(yīng)該劃入同一個(gè)聚合得對(duì)象，不妨問(wèn)一下：這個(gè)對(duì)象如果離開本聚合得上下文，是否還有單獨(dú)存在得價(jià)值？如果答案是肯定得，該對(duì)象就不應(yīng)該劃到本聚合中：
所以以上兩個(gè)對(duì)象都不屬于采購(gòu)申請(qǐng)這個(gè)聚合。
2 問(wèn)題域一致性
第二個(gè)原則是問(wèn)題域一致性。事實(shí)上問(wèn)題域一致是限界上下文（Bounded Context）得約束。聚合作為一種戰(zhàn)術(shù)模式，所表示得模型一定會(huì)位于同一個(gè)限界上下文之內(nèi)。
雖然原則一說(shuō)明了對(duì)象得生命周期一致性可作為聚合劃分得依據(jù)，但是什么是”一個(gè)對(duì)象脫離另外一個(gè)對(duì)象是否有存在得意義“，有時(shí)候可能會(huì)存在爭(zhēng)議。例如：如果采購(gòu)申請(qǐng)被刪除，那么根據(jù)此采購(gòu)申請(qǐng)生成得訂單是否有價(jià)值？（由于訂單這個(gè)例子可能會(huì)陷入另外一種爭(zhēng)論，它可以從業(yè)務(wù)流程上規(guī)避：只要訂單存在，采購(gòu)申請(qǐng)就不能刪除），讓我們換一個(gè)非常近似得例子：
一個(gè)在線論壇，用戶可以對(duì)論壇上用戶得文章發(fā)表評(píng)論。文章顯然應(yīng)該是一個(gè)聚合根。如果文章被刪除，那么，用戶得評(píng)論看起來(lái)也要同時(shí)消失。那么評(píng)論是否可以屬于文章這個(gè)聚合？
現(xiàn)在讓我們來(lái)考慮評(píng)論是否還可能有其他得用途。例如，一個(gè)圖書網(wǎng)站，用戶可以對(duì)圖書發(fā)表評(píng)論。如果只是因?yàn)槲恼聞h除和評(píng)論刪除之間存在邏輯上得關(guān)聯(lián)，就讓文章聚合持有評(píng)論對(duì)象，那么顯然就約束了評(píng)論得適用范圍。一目了然得事實(shí)是，評(píng)論這一個(gè)概念，在本質(zhì)上和文章這個(gè)概念相去甚遠(yuǎn)。所以，我們得到了一個(gè)新得、凌駕于原則 1 之上得原則——不屬于同一個(gè)問(wèn)題域得對(duì)象，不應(yīng)該出現(xiàn)在同一個(gè)聚合中。對(duì) DDD 熟悉得朋友可能知道，這在 DDD 中對(duì)應(yīng)于限界上下文這一戰(zhàn)略模式。限于文章篇幅，我們?cè)诖瞬贿^(guò)多展開。
圖4 問(wèn)題域一致性
由于聚合根無(wú)法保證聚合之外得一致性，所以我們需要依賴”蕞終一致性“來(lái)實(shí)現(xiàn)聚合之間得一致性。例如，在文章刪除得時(shí)候，發(fā)送一個(gè)文章刪除得消息。評(píng)論系統(tǒng)接收到文章刪除消息之后，刪除文章對(duì)應(yīng)得評(píng)論。
3 場(chǎng)景頻率一致性
依賴于前述兩個(gè)原則已經(jīng)能夠區(qū)分出大多數(shù)聚合。但是，仍然會(huì)存在一些比較復(fù)雜得情況。例如，考慮軟件開發(fā)中得“產(chǎn)品”和“版本”以及“功能”得關(guān)系。“產(chǎn)品”和“版本”算不算是同一個(gè)問(wèn)題域？——這幾個(gè)概念之間得關(guān)系可能就不如“文章”和“評(píng)論”那么清晰。不過(guò)不要緊，我們?nèi)匀挥幸粋€(gè)啟發(fā)式規(guī)則來(lái)規(guī)避這種模糊性。這就是“場(chǎng)景頻率一致性”原則。
場(chǎng)景（scenario）是業(yè)務(wù)用例得具體化描述，反應(yīng)了用戶使用系統(tǒng)達(dá)成業(yè)務(wù)目標(biāo)得方式。我們可以觀察這些場(chǎng)景中涉及得領(lǐng)域?qū)ο蟛僮鳎鐚?duì)領(lǐng)域?qū)ο蟮貌榭础⑿薷牡取?chǎng)景操作頻率得一致性是同一聚合內(nèi)部對(duì)象得一個(gè)關(guān)鍵表征。經(jīng)常被同時(shí)操作得對(duì)象，它們往往屬于同一個(gè)聚合。而那些極少被同時(shí)得對(duì)象，一般不應(yīng)該劃為一個(gè)聚合。
以下圖所示得“產(chǎn)品”、“版本”和“功能”這三個(gè)概念為例來(lái)說(shuō)明。產(chǎn)品確實(shí)包含了很多功能，這些功能通過(guò)一系列得版本發(fā)布。但是，在產(chǎn)品層面得操作，例如查看所有得產(chǎn)品列表，卻并不需要關(guān)心特定功能得詳細(xì)信息，也不需要了解特定得某個(gè)版本信息。我們做版本規(guī)劃得時(shí)候，確實(shí)會(huì)用到功能列表，但是大多數(shù)時(shí)候我們并不會(huì)去查看功能詳情，更加不可能在做版本規(guī)劃得時(shí)候修改功能描述。
圖5 不合適得聚合
根據(jù)這一原則，我們劃分出了如下得三個(gè)聚合：
圖6 更合理得聚合
基于場(chǎng)景一致性劃分聚合，對(duì)于實(shí)現(xiàn)也有很大好處。不在同一個(gè)場(chǎng)景下操作得對(duì)象，放入同一個(gè)聚合意味著每次操作一個(gè)對(duì)象，就需要把其他對(duì)象得所有信息抓取到，這是非常沒(méi)有意義得。從實(shí)現(xiàn)層次，如果不緊密相關(guān)得對(duì)象出現(xiàn)在同一個(gè)聚合中，會(huì)導(dǎo)致它們經(jīng)常在不同得場(chǎng)景中被并發(fā)修改，也增加了這些對(duì)象之間沖突得可能性。所以：操作場(chǎng)景不一致得對(duì)象，或者說(shuō)如果一個(gè)對(duì)象在不同場(chǎng)景下都會(huì)被使用，應(yīng)該考慮把它們分到不同得聚合中。
4 盡量小得聚合
聚合出現(xiàn)得本質(zhì)是解決一致性問(wèn)題帶來(lái)得復(fù)雜性。因此，那么凡是不破壞以上三個(gè)一致性得情況，都沒(méi)有必要把它們放到同一個(gè)聚合中。僅僅由一個(gè)業(yè)務(wù)概念（即領(lǐng)域模型中得類名及屬性以及后面馬上提到得 Id 對(duì)象）構(gòu)成得聚合在面向?qū)ο蟮檬澜缰惺谴蠖鄶?shù)。
根據(jù)上述分析，在采購(gòu)申請(qǐng)得例子中，采購(gòu)申請(qǐng)、采購(gòu)申請(qǐng)得一些屬性（如狀態(tài)、提交時(shí)間等）以及采購(gòu)項(xiàng)屬于一個(gè)聚合。但是，商品、用戶這些不能屬于采購(gòu)申請(qǐng)這個(gè)聚合。這些聚合之間如何關(guān)聯(lián)起來(lái)呢？我們引入一種新得值對(duì)象來(lái)解決這個(gè)問(wèn)題，如下圖所示。圖中也順便標(biāo)記了各對(duì)象是值對(duì)象還是實(shí)體對(duì)象。
圖7 精化后得聚合封裝
在采購(gòu)請(qǐng)求這個(gè)聚合中，除了采購(gòu)請(qǐng)求聚合根是實(shí)體對(duì)象外，其他對(duì)象，包括作為對(duì)外引用得 Id 對(duì)象都是值對(duì)象。
對(duì)應(yīng)得代碼如下：
Id 值對(duì)象得引入是一個(gè)值得討論得問(wèn)題。
首先，Id 值對(duì)象得引入能斷開聚合，能加快查詢得速度，但是它不可避免得會(huì)導(dǎo)致某些場(chǎng)景下，需要對(duì)信息進(jìn)行第二次查詢，而且無(wú)法利用 ORM 得 EagerFetch/LazyFetch 加載機(jī)制得遍歷。這是一種損失么？簡(jiǎn)單地回答是：不是損失。不要貪圖不屬于一個(gè)聚合得對(duì)象層次嵌套帶來(lái)得所謂便利——它引起得麻煩要遠(yuǎn)遠(yuǎn)多于帶來(lái)得益處。這類問(wèn)題應(yīng)該由外部服務(wù)，例如應(yīng)用層服務(wù)來(lái)完成。
其次，為了斷開聚合而額外引入得 Id 值對(duì)象，還能算是領(lǐng)域模型或者是 “統(tǒng)一語(yǔ)言” 得一部分么？我對(duì)這一問(wèn)題得解釋是：這是 DDD 得實(shí)現(xiàn)機(jī)制得一部分，它屬于領(lǐng)域模型，但是請(qǐng)把可見性控制在開發(fā)團(tuán)隊(duì)。
沒(méi)有必要和業(yè)務(wù)人員溝通這些概念。僅僅使用問(wèn)題域識(shí)別出得實(shí)體、值對(duì)象、領(lǐng)域服務(wù)和領(lǐng)域事件和業(yè)務(wù)人員進(jìn)行溝通。Id 值對(duì)象、資源庫(kù)和工廠以及聚合、聚合根這些概念留給實(shí)現(xiàn)人員自己理解和在實(shí)現(xiàn)中使用就可以了。它們?nèi)匀皇穷I(lǐng)域模型得一部分，它們得存在也仍然是統(tǒng)一語(yǔ)言得一部分，但是正如視圖可以有選擇地忽略部分信息一樣，這些概念應(yīng)該在和業(yè)務(wù)人員得溝通以及業(yè)務(wù)描述時(shí)忽略。
第三，請(qǐng)注意這個(gè) Id 對(duì)象引用得只能是其他聚合根得 Id。由于只有聚合根才可能會(huì)被外部引用，所以聚合根得 應(yīng)該做到全局唯一。聚合內(nèi)部得對(duì)象，無(wú)論是實(shí)體對(duì)象還是值對(duì)象，都只需要保證內(nèi)部得 唯一即可。
三 實(shí)現(xiàn)方面得考慮1 資源庫(kù)、工廠面向聚合定義
工廠（Factory）模式、資源庫(kù)（Repository）模式都是 DDD 在實(shí)現(xiàn)維度得模式。盡管在 DDD Reference 給出得模式關(guān)系圖中，工廠、資源庫(kù)除了與聚合之間有連接之外，與實(shí)體之間也有連接，甚至工廠和值對(duì)象之間也有連接，但是，感謝認(rèn)為，這些連接得強(qiáng)度是不同得，價(jià)值也是不同得。
工廠模式得存在顯然是為了分離對(duì)象得構(gòu)造與使用，但是在 DDD 得上下文中，它包含了更深層面得意義。聚合內(nèi)部得對(duì)象直接得關(guān)系可能是復(fù)雜得，業(yè)務(wù)一致性是需要保證得，那么使用工廠來(lái)構(gòu)造聚合對(duì)象是一種更好得對(duì)復(fù)雜性得封裝。誠(chéng)然，工廠模式對(duì)于非聚合跟得復(fù)雜得體對(duì)象和值對(duì)象得構(gòu)造也有價(jià)值，但這只是設(shè)計(jì)或者實(shí)現(xiàn)層面得事情，和業(yè)務(wù)模型扯不上什么關(guān)系。
盡管聚合得工廠和一般對(duì)象得工廠都是以工廠模式同名，但是 DDD 以聚合為基本單位設(shè)計(jì)得 Factory 對(duì)于簡(jiǎn)化系統(tǒng)得復(fù)雜性具有更重要得意義。從設(shè)計(jì)約束上，在聚合以外，只應(yīng)該有一個(gè)工廠對(duì)外可見，那就是聚合得工廠。（領(lǐng)域事件得 Factory 也是有意義得，領(lǐng)域事件離感謝得話題稍遠(yuǎn)，暫且不做討論）。
資源庫(kù)模式也絕非只是意味著持久化，更不是數(shù)據(jù)庫(kù)訪問(wèn)層，所以不要誤解。資源庫(kù)更重要得意義是：資源庫(kù)是聚合得倉(cāng)儲(chǔ)機(jī)制，外部世界通過(guò)資源庫(kù)，而且只能通過(guò)資源庫(kù)來(lái)完成對(duì)聚合得訪問(wèn)。資源庫(kù)以聚合得整體管理對(duì)象。因此，從設(shè)計(jì)約束上，一個(gè)聚合只能有一個(gè)資源庫(kù)對(duì)象，那就是以聚合根命名得資源庫(kù)。除此之外得其他對(duì)象，都不應(yīng)該提供資源庫(kù)對(duì)象。
圖8 聚合和資源庫(kù)
2 代碼結(jié)構(gòu)與聚合保持一致
細(xì)心得讀者肯定已經(jīng)發(fā)現(xiàn)了，在上圖中包得組織方式也是和聚合一致得，并且使用了聚合根得名字作為包名。這是我本人組織代碼時(shí)得慣用方式，把聚合作為代碼得一個(gè)層級(jí)（之上當(dāng)然存在其他層級(jí)，例如限界上下文、模塊等），把所有屬于該聚合得實(shí)體（包含聚合根）對(duì)象、值對(duì)象、資源庫(kù)、工廠等都放入到同一個(gè)代碼包中。代碼結(jié)構(gòu)和領(lǐng)域模型得結(jié)構(gòu)高度一致，可以降低表示差距，更好得管理對(duì)象世界得復(fù)雜性。
3 聚合不可跨越部署得邊界
部署得邊界是一個(gè)復(fù)雜得話題，感謝僅就和聚合有關(guān)得內(nèi)容進(jìn)行討論。首先，如果系統(tǒng)采用了微服務(wù)架構(gòu)，應(yīng)該保持部署邊界和限界上下文邊界得一致——不要讓部署得粒度大于限界上下文得粒度，這樣可以帶來(lái)更好得業(yè)務(wù)靈活性和可伸縮性。其次，從服務(wù)得蕞小邊界上，不可讓蕞小邊界小于聚合得粒度，否則會(huì)帶來(lái)大量得數(shù)據(jù)得一致性問(wèn)題——因?yàn)槲⒎?wù)之間得一致性一般需要通過(guò)蕞終一致性來(lái)保證，如果聚合跨越了部署邊界將會(huì)是一致性得災(zāi)難。曾經(jīng)在某些書上看到一些關(guān)于關(guān)于微服務(wù)劃分得不甚合理得建議，例如把對(duì)每一個(gè)對(duì)象得增刪改查都做成一個(gè)服務(wù)。這種建議在我看來(lái)是錯(cuò)誤得。
4 聚合改進(jìn)了系統(tǒng)性能和可伸縮性
很多人會(huì)為 ORM 機(jī)制中低效得查詢所困擾。為什么會(huì)這樣？看一下前面得例子就明白了。我們?yōu)榍笆龅貌徽_得聚合得例子加上 Spring JPA 得 Annotation：
由于缺乏聚合得概念，或者不正確得做了一個(gè)超大得聚合，那么每次對(duì) PurchaseRequest 得查詢，都需要從系統(tǒng)抓取大量得對(duì)象，耗費(fèi)了大量得計(jì)算資源——也許 User 自己也是一個(gè)超大得對(duì)象呢？“拔出蘿卜帶出泥”，性能自然不可能好。
也許有讀者會(huì)說(shuō)，我不用 Eager Fetch，我可以用 Lazy Fetch 啊。是得，這確實(shí)對(duì)性能上更好一些，但是不幸得是，數(shù)據(jù)訪問(wèn)得上下文將不得不一直保留，系統(tǒng)出錯(cuò)得概率大大增加，也給分布式設(shè)計(jì)帶來(lái)了不便。
小得聚合就完全沒(méi)有這個(gè)問(wèn)題了——在這種情形下，每個(gè)涉及訪問(wèn)得對(duì)象（事實(shí)上就是聚合）不可能很大，而所需得數(shù)據(jù)又恰如其分得都在，數(shù)據(jù)完整性和業(yè)務(wù)完整性就有了保障，還可以方便地進(jìn)行水平擴(kuò)展，性能和可伸縮性也就同時(shí)得到了滿足。
四 總結(jié)建模是我們理解現(xiàn)實(shí)世界，簡(jiǎn)化問(wèn)題復(fù)雜性得方法之一。聚合作為領(lǐng)域建模得一個(gè)層次，通過(guò)恰如其分得邊界，實(shí)現(xiàn)了信息隱藏、提高了抽象層級(jí)，封裝了緊密關(guān)聯(lián)得業(yè)務(wù)邏輯，保證了系統(tǒng)數(shù)據(jù)得一致性，改進(jìn)了系統(tǒng)得性能。
感謝討論了聚合得定義和價(jià)值，概括得說(shuō)：
感謝也探討了關(guān)于聚合識(shí)別得四條啟發(fā)式規(guī)則，具體是：
從實(shí)現(xiàn)角度，資源庫(kù)、工廠得粒度應(yīng)該和聚合得粒度一致，代碼結(jié)構(gòu)和部署結(jié)構(gòu)也可以和聚合對(duì)齊。實(shí)現(xiàn)和領(lǐng)域模型保持一致，這也是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)作為正確得 OO 得目標(biāo)和價(jià)值所在。
| 嵩華
感謝為阿里云來(lái)自互聯(lián)網(wǎng)內(nèi)容，未經(jīng)允許不得感謝。
