聚合是領域驅動設計DDD中最容易被誤解的概念之一，只是一堆實體和值物件嗎？還是更多？

什麼是聚合？當然，這是領域驅動設計的核心模式……但這只是物件的集合嗎？

馬丁·福勒（Martin Fowler）解釋說：

聚合是資料儲存傳輸的基本元素–您請求載入或儲存整個聚合。事務不應跨越聚合邊界。

https://www.martinfowler.com/bliki/DDD_Aggregate.html

那些具有DDD經驗的人可能會理解這意味著什麼以及為什麼應用它。但是對於那些開始熟悉聚合的人來說，這樣的解釋可能仍然過於詳細和細微。

讓我們開始看看什麼不是聚合：

什麼不是聚合？

聚合不是下列情況：

• 只是實體圖
• 僅僅是一個行為豐富的物件
• 您可以轉儲到資料庫表中的一個實體或實體集合

那它是什麼？

人們通常在這裡開始談論一致性邊界、事務一致性、最終一致性、聚合邊界、不變式、聚合根等。

當學習這些東西時，很自然地抓住所有熟悉的術語或想法。從那裡，我們（錯誤地）形成了關於這一切的想法。讓我們嘗試使事情簡單實用。

氣泡

我喜歡使用一個非常簡單的想法來幫助人們理解聚合的本質：氣泡。

想象一下，您的軟體專案不是一個龐大的程式碼庫，而是一系列小氣泡。每個氣泡都可以獨立處理。這意味著，您只需要考慮在任何給定時刻的氣泡中發生了什麼，而不是整個系統一次就想到。

聚合是相同的。他們是一個個較小泡泡。

用例：團隊

想象一下，我們正在為系統構建新功能。此新功能包括專案，團隊和團隊成員的概念。

每個團隊可以有多個與之關聯的員工。

工作人員可以是多個團隊的一部分。

每個團隊可以有多個專案。

那看起來不像實體圖嗎？主管資料庫表的DBA不會對您大喊大叫嗎？顯然，我們需要有一個組合表，將每個團隊與每個團隊成員聯絡起來。

等一下。

讓我們考慮一下物件的行為，讓我們將它們視為業務物件或概念。這些物件可以做什麼？

好吧，不是很清楚嗎？您可以建立一個團隊。編輯團隊。刪除團隊。

顯然，刪除團隊意味著所有關聯的專案也應該層疊並刪除。

真正的業務不是那麼簡單

可是等等。您只是從使用者那裡發現這是行不通的。您對業務所做的假設是錯誤的……

有時專案從一個團隊轉移到另一個團隊。在某些情況下，有時還會孤立專案。

我們的模型現在應該是什麼樣？編寫程式碼時，是否應該將整個物件圖載入到記憶體中？

孤立專案時會發生什麼？團隊會只引用一個空專案物件嗎？

更多使事情複雜化的需求

現在，企業有了新的要求：團隊成員的角色可以根據專案而改變。

那麼……我們是否只是建立另一個組合表來使每個團隊成員與他們所從事的每個專案以及每個專案的角色相匹配？

那就是我們通常要做的。開發人員自然會首先從資料庫設計角度考慮系統。

注意：是的，這是領域驅動的設計試圖避免的一個巨大問題！

隨著每個新的新需求，我們的模型變得越來越腫。隨著時間的流逝，這也可能會佔用我們系統中的大量記憶體。想象一個專案的團隊有300名成員。是的，這些是我們正在談論的大型專案。我們需要將所有工作人員及其所有資料載入到記憶體中！

有沒有更好的辦法？

聚合

聚合就是解決此類問題的方法。

他們幫助：

• 當他們開始失控時簡化我們的模型
• 隔離複雜的業務規則
• 將大型物件圖載入到記憶體時處理效能問題
• 提供靈活性，可以更輕鬆地應對未來的意外業務需求

這就是聚合的目的。好！但是他們是什麼？在這裡，我不告訴是什麼，只是告訴您這種情況（否則，我們需要開始談論一致性，事務邊界，併發等等！）。

注意，我將原始成員模型分為三個部分嗎？

團隊Team和專案Project對成員member擁有自己專用的“版本”或“檢視”：Team Member和Project Member，這兩個相似又不同的Member具有特定的業務規則和行為所需的確切資料。例如，團隊Team聚合不需要專案Project聚合的成員member才需要的角色ProjectRole，不屬於它的時候為什麼要放在那裡呢？因此，我們將Member模型劃分為兩個“分支”：Team Member和Project Member。在這種情況下，就有了兩個聚合。

但是，為了支援能夠將同一個成員member分配給多個團隊Team，我們必須建立一個專門的團隊成員授權模型，並將另一個聚合的成員實體連結為類似外來鍵的引用（再次，我們不是在談論資料庫）。

還有更多的要討論。我們可以圍繞使用值物件等對該模型進行更多改進。

我認為這足以幫助您看到聚合不僅僅是簡單地建立實體圖。

這是關於允許業務領域規則指導您的設計。