簡介：聚合模式是 DDD 的模式結(jié)構(gòu)中較為難于理解的一個，也是 DDD 學習曲線中的一個關鍵障礙。合理地設計聚合，能清晰地表述業(yè)務一致性，也更容易帶來清晰的實現(xiàn)，設計不合理的聚合，甚至在設計中沒有聚合的概念，則相反。

作者 | 嵩華
來源 | 阿里技術公眾號

聚合模式是 DDD 的模式結(jié)構(gòu)中較為難于理解的一個，也是 DDD 學習曲線中的一個關鍵障礙。合理地設計聚合，能清晰地表述業(yè)務一致性，也更容易帶來清晰的實現(xiàn)，設計不合理的聚合，甚至在設計中沒有聚合的概念，則相反。

聚合的概念并不復雜。本文希望能回到聚合的本質(zhì)，對聚合的定義和實操給出一些有價值的建議。

一 聚合解決的核心問題是什么

我們先來看一下在 DDD Reference 中關于聚合的定義。

將實體和值對象劃分為聚合并圍繞著聚合定義邊界。選擇一個實體作為每個聚合的根，并僅允許外部對象持有對聚合根的引用。作為一個整體來定義聚合的屬性和不變量，并把其執(zhí)行責任賦予聚合根或指定的框架機制。

這是典型的“模式語言”，說明了聚合是什么，聚合根（aggregation root）是什么，以及如何使用聚合。但是，模式語言的問題在于過度精煉，如果讀者已經(jīng)熟悉了這種模式，很容易看懂，但是最需要看懂的、那些尚不夠熟悉這些概念的人，卻容易感到不知所云。為了能深入理解一個模式的本質(zhì)，我們還是要回到它試圖解決的核心問題上來。

在軟件架構(gòu)領域有一句名言：

“架構(gòu)并不由系統(tǒng)的功能決定，而是由系統(tǒng)的非功能屬性決定”。

這句話直白的解釋就是：假如不考慮性能、健壯性、可移植性、可修改性、開發(fā)成本、時間約束等因素，用任何的架構(gòu)、任何的方法，系統(tǒng)的功能總是可以實現(xiàn)的，項目總是能開發(fā)完成的，只是開發(fā)時間、以后的維護成本、功能擴展的容易程度不同罷了。

當然現(xiàn)實絕非如此。我們總是希望系統(tǒng)在可理解、可維護、可擴展等方面表現(xiàn)良好，從而多快好省的達成系統(tǒng)背后的業(yè)務目標。但是，在現(xiàn)實中，不合理的設計方法有可能增加系統(tǒng)的復雜性。我們先來看一個例子：

假設問題領域是一個企業(yè)內(nèi)部的辦公用品采購系統(tǒng)。

• 企業(yè)的員工可以通過該系統(tǒng)提交一個采購請求，一個請求包含了若干數(shù)量、若干類型的辦公用品（稱為采購項）。(1)
• 主管負責對采購申請進行審批。(2)
• 審批通過后，系統(tǒng)會根據(jù)提供商不同，生成若干訂單。(3)

對同一個問題，存在若干種不同的設計思路，例如以數(shù)據(jù)庫為中心的設計、面向?qū)ο蟮脑O計和“正確的 OO”的 DDD 的設計。

如果采用以數(shù)據(jù)庫為中心的建模方式，首先會進行數(shù)據(jù)庫設計——我確實看到還有許多團隊仍然在采取這種方法，花費大量的時間進行數(shù)據(jù)庫結(jié)構(gòu)的討論。為了避免圖表過大，我們僅僅給出了和采購申請相關的表格。結(jié)構(gòu)如下圖所示：

圖1 數(shù)據(jù)庫視角下的設計

如果直接在數(shù)據(jù)庫這么低的設計層次上考慮問題，除了數(shù)據(jù)庫的設計繁瑣易錯，更重要的是會面臨一些比較復雜的業(yè)務規(guī)則和數(shù)據(jù)一致性保證的問題。例如：

• 如果采購請求被刪除，則相應的和該采購請求相關的采購項以及它們之間的關聯(lián)都需要被刪除——在數(shù)據(jù)庫設計中，這種約束可以通過數(shù)據(jù)庫外鍵來保證。
• 如果多個用戶在對具有相關關系的數(shù)據(jù)進行并發(fā)處理，則可能涉及到復雜的鎖定機制。例如，如果審批者正在對采購請求進行審批，而采購提交者正在對采購項進行修改，則就有可能導致審核的數(shù)據(jù)是過期數(shù)據(jù)，或者導致采購項更新的失敗。
• 如果同時更新某些相關聯(lián)的數(shù)據(jù)，也可能面臨部分更新成功導致的問題——在數(shù)據(jù)庫設計中，這類約束則需要通過 transaction 來保證。

確實，每個問題都是有解決方案的，但是，第一，對于模型的討論過早地進入了實現(xiàn)領域，和業(yè)務概念脫開了聯(lián)系，不便于持續(xù)地和業(yè)務人員協(xié)作；第二，技術細節(jié)和業(yè)務規(guī)則的細節(jié)糾纏在一起，很容易顧此失彼。有沒有一種方案，可以讓我們更多的聚焦于問題領域，而不是深陷到這種技術細節(jié)中？

面向?qū)ο蠹夹g和 ORM（對象-關系映射）有助于我們提高問題的抽象層級。在面向?qū)ο蟮氖澜缰?#xff0c;我們看到的結(jié)構(gòu)是這樣的：

圖2 傳統(tǒng)OO視角下的設計

面向?qū)ο蟮姆绞教岣吡顺橄髮蛹?#xff0c;忽略了不必要的技術細節(jié)，例如已經(jīng)不需要關心外鍵、關聯(lián)表這些技術細節(jié)了。我們需要關心的模型元素的數(shù)量減少了，復雜性也相應減少了。只是，業(yè)務規(guī)則如何保證，在傳統(tǒng)的面向?qū)ο蠓椒ㄖ胁]有嚴格的實現(xiàn)約束。例如：

從業(yè)務角度來看，如果采購申請的審批已經(jīng)通過，對采購申請的采購項進行再次更新應該是非法的。但是，在面向?qū)ο蟮氖澜缰?#xff0c;你卻沒法阻止程序員寫出這樣的代碼：

... PurchaseRequest purchaseRequest = getPurchaseRequest(requestId); PurchaseItem item = purchaseRequest.getItem(itemId); item.setQuantity(1000); savePurchaseItem(item);

語句 1 取得了一個采購申請的實例；語句 2 取得了該申請中的一個條目。語句 3 和 4 修改了采購申請條目并保存。假如采購申請已經(jīng)審批通過，這種修改豈不是可以輕易突破采購申請的預算？

當然，程序員可以在代碼中加入邏輯檢查來保證一致性：在修改或保存申請條目前總是檢查 purchaseRequest 的狀態(tài)，如果狀態(tài)不為草稿就禁止修改。但是，考慮到 PurchaseItem 對象可以在代碼的任何位置被取出來，且可能在不同的方法間傳遞，如果 OO 設計不當，就可能導致該業(yè)務邏輯分散到各處。沒有設計約束，這種檢查的實現(xiàn)并不是一件容易的事情。

讓我們回到本質(zhì)思考：采購項如果脫離采購請求，它自身的單獨存在有價值嗎？——沒有價值。如果沒有價值：名義上看起來對采購項的修改，本質(zhì)上是對采購項的修改嗎？還是本質(zhì)上其實是對采購請求的修改？

如果我們認可“修改采購項也是修改采購請求”這個結(jié)論，那么我們就不應該分開來研究采購項和采購請求，而是應該如下圖所示：

圖3 用聚合封裝對象

我們把“采購請求”和“采購項”組織到一起，看做一個更大的整體，稱為“聚合”。這個聚合內(nèi)部的業(yè)務邏輯，例如“采購申請審核通過后，不得對采購申請條目進行更改”，應內(nèi)建于聚合內(nèi)部。為了實現(xiàn)這一目標，我們約定：對采購項的一切操作（增加、刪除、修改等），都是對采購請求對象的操作。

也就是說：在 DDD 的世界中，從來就不應該存在 savePurchaseItem() 這種方法，而應以 purchaseRequest.modifyPurchaseItem() 和 purchaseRequestRepository.save(purchaseRequest) 取代之。

在新的對象關系中，采購申請負責“把守關隘”（即“聚合根”），采購條目成為了聚合的內(nèi)部數(shù)據(jù)。由于聚合現(xiàn)在已經(jīng)是一個整體，與其相關的操作只能通過采購申請對象進行，業(yè)務一致性就可以得到保證。這事實上也是關于對象之間關系的更精確的描述：雖然采購申請和采購項都被建模為對象，但是它們的地位是不對等的。采購項是從屬于采購申請的對象，它們只有是一個整體才有意義。

聚合的本質(zhì)就是建立了一個比對象粒度更大的邊界，聚集那些緊密關聯(lián)的對象，形成了一個業(yè)務上的對象整體。使用聚合根作為對外的交互入口，從而保證了多個互相關聯(lián)的對象的一致性。合理使用聚合，可以更容易地保證業(yè)務規(guī)則的一致性，減少了對象之間可能的耦合，提升設計的可理解性，降低出問題的可能性。

所以，通過把對象組織為聚合，在基本的對象層次之上構(gòu)造了一層新的封裝。封裝簡化了概念，隱藏了細節(jié)，在外部需要關心的模型元素數(shù)量進一步減少，復雜性下降。但是，封裝邊界的引入也引發(fā)了一個新的問題，例如：商品信息也是采購項的有效部分，應不應該把商品也放入“采購請求”這個聚合呢？提交人和審批人是不是也該放入聚合呢？如果要便利地獲得業(yè)務規(guī)則的一致性，那豈不是把一切存在業(yè)務關聯(lián)的對象都應該放在一起更好？如果有些對象應該放入聚合，有些不應該放入聚合，那么是否存在一個清晰的指導原則？本文在下一節(jié)回答這個問題。

二 聚合劃分的原則

聚合作為 DDD 的對象體系中的一層，也同樣應該遵循高內(nèi)聚、低耦合的原則。本文認為，聚合邊界內(nèi)的對象應滿足如下的啟發(fā)式規(guī)則：

• 生命周期一致性
• 問題域一致性
• 場景頻率一致性
• 聚合內(nèi)的元素盡可能少

1 生命周期一致性

生命周期一致性是指聚合邊界內(nèi)的對象，和聚合根之間存在“人身依附”關系。即：如果聚合根消失，聚合內(nèi)的其他元素都應該同時消失。例如，在前述例子中，如果聚合根（采購請求）不存在了，那么采購項當然也就失去了存在的意義。而商品、作為申請人的用戶等對象，和采購請求之間則不存在此關系。

可以用反證法來證明生命周期一致性：如果一個對象在聚合根消失之后仍然有意義，那么說明在系統(tǒng)中必然需要存在其他方法訪問該對象。這和聚合的定義相矛盾。所以聚合根內(nèi)的其他元素必然在聚合根消失后失效。違反生命周期一致性，也會同時帶來實現(xiàn)上的嚴重問題。讓我們一起看一個例子：

其中 User 對象的生命周期和采購申請不一致。現(xiàn)在假如有兩段程序代碼并行執(zhí)行：

代碼 1（例如采購申請的修改）獲得了某個采購申請的對象，對該對象進行了修改，進行保存。注意由于 User 對象嵌入到了 PurchaseRequest 中，User 對象也會被同時保存。

r = purchaseRequestRepository.findOne(id); //...一些修改 purchaseRequestRepository.save(r);

代碼 2（例如是用戶管理），獲得了該對象對應的審批人的信息，也進行了修改。

User user = userRepo.findOne(r.getSubmitter().getId()); //...一些修改 userRepo.save(user);

這將會導致一種完全不可接受的后果：對于 User 對象的修改不確定性！因此，對于那些說不清楚是否應該劃入同一個聚合的對象，不妨問一下：這個對象如果離開本聚合的上下文，是否還有單獨存在的價值？如果答案是肯定的，該對象就不應該劃到本聚合中：

• Submitter/Approver 對應的 User 對象脫離了 PurchaseRequest，仍然有單獨存在的理由。
• Product 對象脫離了 PurchaseRequest，是可以單獨存在的。

所以以上兩個對象都不屬于采購申請這個聚合。

2 問題域一致性

第二個原則是問題域一致性。事實上問題域一致是限界上下文（Bounded Context）的約束。聚合作為一種戰(zhàn)術模式，所表示的模型一定會位于同一個限界上下文之內(nèi)。

雖然原則一說明了對象的生命周期一致性可作為聚合劃分的依據(jù)，但是什么是”一個對象脫離另外一個對象是否有存在的意義“，有時候可能會存在爭議。例如：如果采購申請被刪除，那么根據(jù)此采購申請生成的訂單是否有價值？（由于訂單這個例子可能會陷入另外一種爭論，它可以從業(yè)務流程上規(guī)避：只要訂單存在，采購申請就不能刪除），讓我們換一個非常近似的例子：

一個在線論壇，用戶可以對論壇上用戶的文章發(fā)表評論。文章顯然應該是一個聚合根。如果文章被刪除，那么，用戶的評論看起來也要同時消失。那么評論是否可以屬于文章這個聚合？

現(xiàn)在讓我們來考慮評論是否還可能有其他的用途。例如，一個圖書網(wǎng)站，用戶可以對圖書發(fā)表評論。如果只是因為文章刪除和評論刪除之間存在邏輯上的關聯(lián)，就讓文章聚合持有評論對象，那么顯然就約束了評論的適用范圍。一目了然的事實是，評論這一個概念，在本質(zhì)上和文章這個概念相去甚遠。所以，我們得到了一個新的、凌駕于原則 1 之上的原則——不屬于同一個問題域的對象，不應該出現(xiàn)在同一個聚合中。對 DDD 熟悉的朋友可能知道，這在 DDD 中對應于限界上下文這一戰(zhàn)略模式。限于文章篇幅，我們在此不過多展開。

圖4 問題域一致性

由于聚合根無法保證聚合之外的一致性，所以我們需要依賴”最終一致性“來實現(xiàn)聚合之間的一致性。例如，在文章刪除的時候，發(fā)送一個文章刪除的消息。評論系統(tǒng)接收到文章刪除消息之后，刪除文章對應的評論。

3 場景頻率一致性

依賴于前述兩個原則已經(jīng)能夠區(qū)分出大多數(shù)聚合。但是，仍然會存在一些比較復雜的情況。例如，考慮軟件開發(fā)中的“產(chǎn)品”和“版本”以及“功能”的關系。“產(chǎn)品”和“版本”算不算是同一個問題域？——這幾個概念之間的關系可能就不如“文章”和“評論”那么清晰。不過不要緊，我們?nèi)匀挥幸粋€啟發(fā)式規(guī)則來規(guī)避這種模糊性。這就是“場景頻率一致性”原則。

場景（scenario）是業(yè)務用例的具體化描述，反應了用戶使用系統(tǒng)達成業(yè)務目標的方式。我們可以觀察這些場景中涉及的領域?qū)ο蟛僮?#xff0c;如對領域?qū)ο蟮牟榭础⑿薷牡取鼍安僮黝l率的一致性是同一聚合內(nèi)部對象的一個關鍵表征。經(jīng)常被同時操作的對象，它們往往屬于同一個聚合。而那些極少被同時關注的對象，一般不應該劃為一個聚合。

以下圖所示的“產(chǎn)品”、“版本”和“功能”這三個概念為例來說明。產(chǎn)品確實包含了很多功能，這些功能通過一系列的版本發(fā)布。但是，在產(chǎn)品層面的操作，例如查看所有的產(chǎn)品列表，卻并不需要關心特定功能的詳細信息，也不需要了解特定的某個版本信息。我們做版本規(guī)劃的時候，確實會用到功能列表，但是大多數(shù)時候我們并不會去查看功能詳情，更加不可能在做版本規(guī)劃的時候修改功能描述。

圖5 不合適的聚合

根據(jù)這一原則，我們劃分出了如下的三個聚合：

圖6 更合理的聚合

基于場景一致性劃分聚合，對于實現(xiàn)也有很大好處。不在同一個場景下操作的對象，放入同一個聚合意味著每次操作一個對象，就需要把其他對象的所有信息抓取到，這是非常沒有意義的。從實現(xiàn)層次，如果不緊密相關的對象出現(xiàn)在同一個聚合中，會導致它們經(jīng)常在不同的場景中被并發(fā)修改，也增加了這些對象之間沖突的可能性。所以：操作場景不一致的對象，或者說如果一個對象在不同場景下都會被使用，應該考慮把它們分到不同的聚合中。

4 盡量小的聚合

聚合出現(xiàn)的本質(zhì)是解決一致性問題帶來的復雜性。因此，那么凡是不破壞以上三個一致性的情況，都沒有必要把它們放到同一個聚合中。僅僅由一個業(yè)務概念（即領域模型中的類名及屬性以及后面馬上提到的 Id 對象）構(gòu)成的聚合在面向?qū)ο蟮氖澜缰惺谴蠖鄶?shù)。

根據(jù)上述分析，在采購申請的例子中，采購申請、采購申請的一些屬性（如狀態(tài)、提交時間等）以及采購項屬于一個聚合。但是，商品、用戶這些不能屬于采購申請這個聚合。這些聚合之間如何關聯(lián)起來呢？我們引入一種新的值對象來解決這個問題，如下圖所示。圖中也順便標記了各對象是值對象還是實體對象。

圖7 精化后的聚合封裝

在采購請求這個聚合中，除了采購請求聚合根是實體對象外，其他對象，包括作為對外引用的 Id 對象都是值對象。

對應的代碼如下：

Id 值對象的引入是一個值得討論的問題。

首先，Id 值對象的引入能斷開聚合，能加快查詢的速度，但是它不可避免的會導致某些場景下，需要對信息進行第二次查詢，而且無法利用 ORM 的 EagerFetch/LazyFetch 加載機制的遍歷。這是一種損失嗎？簡單地回答是：不是損失。不要貪圖不屬于一個聚合的對象層次嵌套帶來的所謂便利——它引起的麻煩要遠遠多于帶來的益處。這類問題應該由外部服務，例如應用層服務來完成。

其次，為了斷開聚合而額外引入的 Id 值對象，還能算是領域模型或者是 “統(tǒng)一語言” 的一部分嗎？我對這一問題的解釋是：這是 DDD 的實現(xiàn)機制的一部分，它屬于領域模型，但是請把可見性控制在開發(fā)團隊。

沒有必要和業(yè)務人員溝通這些概念。僅僅使用問題域識別出的實體、值對象、領域服務和領域事件和業(yè)務人員進行溝通。Id 值對象、資源庫和工廠以及聚合、聚合根這些概念留給實現(xiàn)人員自己理解和在實現(xiàn)中使用就可以了。它們?nèi)匀皇穷I域模型的一部分，它們的存在也仍然是統(tǒng)一語言的一部分，但是正如視圖可以有選擇地忽略部分信息一樣，這些概念應該在和業(yè)務人員的溝通以及業(yè)務描述時忽略。

第三，請注意這個 Id 對象引用的只能是其他聚合根的 Id。由于只有聚合根才可能會被外部引用，所以聚合根的 ID 應該做到全局唯一。聚合內(nèi)部的對象，無論是實體對象還是值對象，都只需要保證內(nèi)部的 ID 唯一即可。

三 實現(xiàn)方面的考慮

1 資源庫、工廠面向聚合定義

工廠（Factory）模式、資源庫（Repository）模式都是 DDD 在實現(xiàn)維度的模式。盡管在 DDD Reference 給出的模式關系圖中，工廠、資源庫除了與聚合之間有連接之外，與實體之間也有連接，甚至工廠和值對象之間也有連接，但是，本文認為，這些連接的強度是不同的，價值也是不同的。

工廠模式的存在顯然是為了分離對象的構(gòu)造與使用，但是在 DDD 的上下文中，它包含了更深層面的意義。聚合內(nèi)部的對象直接的關系可能是復雜的，業(yè)務一致性是需要保證的，那么使用工廠來構(gòu)造聚合對象是一種更好的對復雜性的封裝。誠然，工廠模式對于非聚合跟的復雜的體對象和值對象的構(gòu)造也有價值，但這只是設計或者實現(xiàn)層面的事情，和業(yè)務模型扯不上什么關系。

盡管聚合的工廠和一般對象的工廠都是以工廠模式同名，但是 DDD 以聚合為基本單位設計的 Factory 對于簡化系統(tǒng)的復雜性具有更重要的意義。從設計約束上，在聚合以外，只應該有一個工廠對外可見，那就是聚合的工廠。（領域事件的 Factory 也是有意義的，領域事件離本文的話題稍遠，暫且不做討論）。

資源庫模式也絕非只是意味著持久化，更不是數(shù)據(jù)庫訪問層，所以不要誤解。資源庫更重要的意義是：資源庫是聚合的倉儲機制，外部世界通過資源庫，而且只能通過資源庫來完成對聚合的訪問。資源庫以聚合的整體管理對象。因此，從設計約束上，一個聚合只能有一個資源庫對象，那就是以聚合根命名的資源庫。除此之外的其他對象，都不應該提供資源庫對象。

圖8 聚合和資源庫

2 代碼結(jié)構(gòu)與聚合保持一致

細心的讀者肯定已經(jīng)發(fā)現(xiàn)了，在上圖中包的組織方式也是和聚合一致的，并且使用了聚合根的名字作為包名。這是我本人組織代碼時的慣用方式，把聚合作為代碼的一個層級（之上當然存在其他層級，例如限界上下文、模塊等），把所有屬于該聚合的實體（包含聚合根）對象、值對象、資源庫、工廠等都放入到同一個代碼包中。代碼結(jié)構(gòu)和領域模型的結(jié)構(gòu)高度一致，可以降低表示差距，更好的管理對象世界的復雜性。

3 聚合不可跨越部署的邊界

部署的邊界是一個復雜的話題，本文僅就和聚合有關的內(nèi)容進行討論。首先，如果系統(tǒng)采用了微服務架構(gòu)，應該保持部署邊界和限界上下文邊界的一致——不要讓部署的粒度大于限界上下文的粒度，這樣可以帶來更好的業(yè)務靈活性和可伸縮性。其次，從服務的最小邊界上，不可讓最小邊界小于聚合的粒度，否則會帶來大量的數(shù)據(jù)的一致性問題——因為微服務之間的一致性一般需要通過最終一致性來保證，如果聚合跨越了部署邊界將會是一致性的災難。曾經(jīng)在某些書上看到一些關于關于微服務劃分的不甚合理的建議，例如把對每一個對象的增刪改查都做成一個服務。這種建議在我看來是錯誤的。

4 聚合改進了系統(tǒng)性能和可伸縮性

很多人會為 ORM 機制中低效的查詢所困擾。為什么會這樣？看一下前面的例子就明白了。我們?yōu)榍笆龅牟徽_的聚合的例子加上 Spring JPA 的 Annotation：

由于缺乏聚合的概念，或者不正確的做了一個超大的聚合，那么每次對 PurchaseRequest 的查詢，都需要從系統(tǒng)抓取大量的對象，耗費了大量的計算資源——也許 User 自己也是一個超大的對象呢？“拔出蘿卜帶出泥”，性能自然不可能好。

也許有讀者會說，我不用 Eager Fetch，我可以用 Lazy Fetch 啊。是的，這確實對性能上更好一些，但是不幸的是，數(shù)據(jù)訪問的上下文將不得不一直保留，系統(tǒng)出錯的概率大大增加，也給分布式設計帶來了不便。

小的聚合就完全沒有這個問題了——在這種情形下，每個涉及訪問的對象（事實上就是聚合）不可能很大，而所需的數(shù)據(jù)又恰如其分的都在，數(shù)據(jù)完整性和業(yè)務完整性就有了保障，還可以方便地進行水平擴展，性能和可伸縮性也就同時得到了滿足。

四 總結(jié)

建模是我們理解現(xiàn)實世界，簡化問題復雜性的方法之一。聚合作為領域建模的一個層次，通過恰如其分的邊界，實現(xiàn)了信息隱藏、提高了抽象層級，封裝了緊密關聯(lián)的業(yè)務邏輯，保證了系統(tǒng)數(shù)據(jù)的一致性，改進了系統(tǒng)的性能。

本文討論了聚合的定義和價值，概括的說：

• 聚合是面向?qū)ο蟮氖澜缰薪５囊粋€層次。它隱藏了細粒度對象，約束了對象之間的耦合。
• 聚合是一致性的邊界，是對具有緊密關聯(lián)關系的對象的封裝。聚合封裝了實體對象和值對象，并且采用其中最重要的一個實體對象作為聚合根。聚合根作為聚合的唯一外部入口，保證了業(yè)務規(guī)則和數(shù)據(jù)的一致性。

本文也探討了關于聚合識別的四條啟發(fā)式規(guī)則，具體是：

• 生命周期一致性
• 問題域一致性
• 場景頻率一致性
• 聚合內(nèi)的元素盡可能少

從實現(xiàn)角度，資源庫、工廠的粒度應該和聚合的粒度一致，代碼結(jié)構(gòu)和部署結(jié)構(gòu)也可以和聚合對齊。實現(xiàn)和領域模型保持一致，這也是領域驅(qū)動設計作為正確的 OO 的目標和價值所在。

---

【2021阿里巴巴研發(fā)效能峰會】開放報名

6月23日，阿里巴巴合伙人、IBM副合伙人、德勤云服務首席架構(gòu)師、PMI業(yè)務副總裁等，近30位海內(nèi)外大咖分享效能趨勢和實踐，云原生、低代碼、智能化、未來架構(gòu)、DevOps、數(shù)字化轉(zhuǎn)型1200分鐘精選干貨匯聚，和你一起感知行業(yè)技術水位，洞悉未來發(fā)展態(tài)勢。

點擊這里，免費預約吧~

原文鏈接：https://developer.aliyun.com/article/784709?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的深入理解领域驱动设计中的聚合的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。