作者|付施威

一、DDD診所 —— 聚合過大綜合癥

“DDD診所”是Thoughtworks DDD社區(qū)的一項活動，通過對同事們在實施DDD過程中遇到的問題進行分析和解答，共同提高開發(fā)水平。我們將其中一些典型案例整理成文供大家參考。之后也會考慮在適當?shù)臅r候?qū)⑦@一形式對外部開放。

(資料圖)

就診日期：2022年6月8日

患者：某DevOps平臺持續(xù)集成模塊

診金：0元（免費義診）

二、【患者主訴】疑似問題設計

某DevOps平臺需提供持續(xù)交付流水線設計功能，使用戶可在界面上規(guī)劃完整流程。因此，流水線設計頁面功能繁雜，涵蓋階段規(guī)劃、前置觸發(fā)條件設置、質(zhì)量門禁控制等。隨著功能擴展，頁面復雜度逐漸提升。此類功能旨在協(xié)助用戶優(yōu)化持續(xù)交付流水線管理，提升交付效能與質(zhì)量。

圖片

持續(xù)交付流水線界面原

功能介紹：

設計不同的階段：用戶可以根據(jù)需要設置不同的階段，例如開發(fā)階段、測試階段等。對于每個階段，用戶可以設置不同的步驟，例如Checkout、編譯、構建鏡像和部署等。設計前置觸發(fā)條件：用戶可以選擇兩種觸發(fā)方式，一種是某個代碼倉庫提交觸發(fā)，另一種是定時任務。用戶可以設置多個前置觸發(fā)條件。設置質(zhì)量門禁：用戶可以選擇給階段設置質(zhì)量門禁，例如單元測試覆蓋率大于80%等。這些門禁指標可以在質(zhì)量門禁管理功能中設置。在流水線執(zhí)行時，如果不滿足門禁指標，會阻止流水線進入下一個階段。

項目架構師在接到需求后，根據(jù)需求設計了一個名為“持續(xù)交付流水線領域模型”。該模型的目的是方便用戶在界面上完成一系列操作，如代碼質(zhì)量檢查、編譯代碼、構建鏡像和部署等。這些操作被看作是一個整體，并被組織在一個叫做“流水線”的聚合中。這個聚合包括質(zhì)量門禁、不同的階段和觸發(fā)規(guī)則等。這種設計旨在保證流水線中各個組成部分的一致性。

請注意，圖中的“<>”是一種自定義的衍生關系，意味著該對象映射自其他上下文。

圖片

持續(xù)交付流水線領域模型

團隊按照這個模型落地了代碼，隨著交付的深入，這個模型的缺點也浮現(xiàn)出來。

引發(fā)問題1. 認知負載上升

這個聚合包含了7個實體（不包括抽象類），每個實體都有自己相關的業(yè)務，因此這個聚合的認知負載相對較大。此外，該部分業(yè)務需要集成不同的外部依賴系統(tǒng)，如Sonar（用于實現(xiàn)質(zhì)量門禁）、定時任務組件（用于定時任務觸發(fā)器）、GitLab或GitHub（用于代碼提交觸發(fā)器）等。盡管可以通過使用Repository模式和依賴倒置原則來分離功能和實現(xiàn)，但開發(fā)人員或維護人員仍需要掌握相關知識。如果某個人接手了這個功能（例如修改質(zhì)量門禁相關功能），他/她基本上需要了解整個系統(tǒng)的工作方式。

2. 部分可用性難以實現(xiàn)

這個功能集成了多個第三方系統(tǒng)，并被設計為一個聚合。由于這些功能中的任何一部分不可用時，整個功能都將受到影響，因此難以實現(xiàn)部分可用性。例如，當Sonar服務暫時不可用時，代碼觸發(fā)和階段維護的部分也無法為用戶提供服務。如果后續(xù)用戶提出了部分可用性需求，要求Sonar不可用的情況下，要提示質(zhì)量門禁設置失敗，但同時，其他部分仍需為用戶提供服務，那么根據(jù)這個設計就很難實現(xiàn)了，只能推倒重建，成本非常高。

不幸的是，在設計過程中我們不知不覺地構建了一個分布式單體。分布式單體架構是對一種設計糟糕的微服務架構的戲稱。一般指那種由于架構師沒有充分考慮和掌握分布式的優(yōu)勢和代價，憑感覺設計出的微服務架構。這種架構導致設計出的系統(tǒng)既不能享受分布式的彈性優(yōu)勢，又丟失了單體服務易于實現(xiàn)ACID事務強一致性方面的便利。通常出現(xiàn)在未經(jīng)良好設計的微服務風格的分布式軟件中。

3. 犧牲了性能和并發(fā)性

當前的交互設計是用戶在設計界面對流水線的各部分進行設計，設計完成后按提交按鈕提交所有部分。實際上，用戶在每次修改時，不一定需要同時修改質(zhì)量門禁、階段、觸發(fā)規(guī)則等所有的部分。然而由于聚合模式的特點，我們每次都需要對整個聚合的所有實體進行整存整取。即使用戶只想修改其中一部分（如“觸發(fā)規(guī)則”），我們?nèi)孕枰旅麨椤傲魉€”的聚合的整個7個模型，這將導致巨大的性能浪費。此外，如果兩個用戶同時操作業(yè)務上互不影響的兩部分如“觸發(fā)規(guī)則”和“質(zhì)量門禁”時，會相互沖突，有一個用戶要被提示“設計已變更，修改失敗”，降低了系統(tǒng)的吞吐量。

三、【診斷】

初步診斷，患者的病情主要是聚合過大綜合癥，即聚合設計不合理，導致聚合過大。在DDD實踐中，合理劃分聚合是個比較有挑戰(zhàn)的問題。

聚合過大綜合癥的病理分析

在DDD的落地實踐過程中，聚合的大小經(jīng)常被描述為一個不可言說的知識。很多時候，憑經(jīng)驗和感覺會導致比較差的設計。然而，在實踐中，識別大聚合仍有跡可循，一般來說，出現(xiàn)了這三種情況時，就需要警惕聚合過大綜合癥：

1. 寬聚合

一個聚合聚合了多個同級實體，一個“父親”多個 “兒子”。如圖所示：一旦超過三就有大聚合的風險。

2. 深聚合

聚合的深度過深，例如聚合根有兒子實體，也有孫子實體，也有重孫實體。當層級達到三層時，就存在大聚合的風險。

3. 胖聚合

盡管結構簡單，但實體對象實例多。例如訂單和訂單行作為了一個聚合，而實際業(yè)務經(jīng)常出現(xiàn)有幾千個訂單行的訂單。這種也存在大聚合的風險。

圖片

聚合過大的三個征兆

正如該案例所表現(xiàn)的那樣，這是一個具有寬聚合和深聚合的聚合過大綜合癥癥狀。聚合過大綜合癥會導致一系列問題，例如認知負荷增加、部分可用性下降以及性能問題。而在該案例中，這些問題正是由聚合過大綜合癥所導致的。

四、【治療建議】

出現(xiàn)聚合過大綜合癥，大多數(shù)情況是由于聚合劃分不合理所導致的。為了解決這個問題，我們可以回顧《領域驅(qū)動設計》一書中有關聚合模式的定義，以了解如何合理地劃分聚合。

識別聚合的方法

在《領域驅(qū)動設計：軟件核心復雜性應對之道》一書中，聚合的定義如下：

在具有復雜關聯(lián)的模型中，要想保證對象更改的一致性是很困難的。需要維護適用于密切相關的對象組的Invariant，而不僅僅是離散的對象。然而，過于謹慎的鎖定機制又會導致多個用戶之間毫無意義地互相干擾，從而使系統(tǒng)不可用。我們應該將 Entity和 Value Object分門別類地聚集到Aggregate中并定義每Aggregate的邊界。在每Aggregate中，選擇一個Entity作為根，并通過根來控制對邊界內(nèi)其他對象的所有訪問。只允許外部對象保持對根的引用。對內(nèi)部成員的臨時引用可以被傳遞出去，但僅在一次操作中有效。由于根控制訪問，因此不能繞過它來修改內(nèi)部對象。這種設計有利于確保Aggregate中的對象滿足所有固定規(guī)則，也可以確保在任何狀態(tài)變化時Aggregate作為一個整體滿足固定規(guī)則。

根據(jù)聚合模式的定義，我們可以得出判斷兩個實體（Entity）是否屬于一個聚合的依據(jù)，需要把握兩個條件：

1. 存在整體部分關系

當某個Entity是另一個Entity的部分時，稱為整體部分關系。例如：

汽車輪胎是汽車的一部分學生是班級的一部分訂單行是訂單的一部分2. 實體之間存在變更時需要遵守的固定規(guī)則（Invariants）

固定規(guī)則或稱為不變量不變式，來自契約式設計。

在計算機科學中，不變量是指在計算機程序執(zhí)行的某一階段始終為真的邏輯論斷。例如，循環(huán)不變量是一個條件，在一個循環(huán)的每個迭代開始和結束時都是真的。--- wiki

在劃分聚合時，我們關注的是一些由業(yè)務原因所約束的固定規(guī)則。這些規(guī)則通常是通過與業(yè)務人員溝通，了解“A更新的時候，會不會引起B(yǎng)的某個屬性的更新”，“如果兩個實體暫時不一致，是否會導致難以承受的業(yè)務后果”等問題來得出的。

例如，在訂單系統(tǒng)中，假設需求是整個訂單的總價等于訂單行的總價之和，且總價必須小于3000（左圖）。在這種情況下，訂單與訂單行之間就存在固定規(guī)則。因此，可以把它們放在同一個聚合中，并通過整存整取來維護這個固定規(guī)則。然而，如果業(yè)務場景是訂單僅作為訂單行的分組，用戶需要按照訂單行逐一結賬（右圖）那么訂單和訂單行就無需劃分成一個聚合。

圖片

固定規(guī)則是劃分聚合的重要條件

需要注意的是，固定規(guī)則中的一部分是由技術實現(xiàn)所約束的固定規(guī)則，例如數(shù)據(jù)庫ID不重復、訂單編號唯一等。這些規(guī)則通常是全局性的固定規(guī)則，需要在整個系統(tǒng)范圍內(nèi)遵循。然而，由于這些全局性的固定規(guī)則通常與特定的業(yè)務邏輯無關，因此在劃分聚合時，它們通常不是參考因素。

大聚合都必須拆小么？

盡管利用業(yè)務固定規(guī)則通常能夠確定較小的業(yè)務一致性邊界，從而得出比較合適的聚合規(guī)模，但并不是所有業(yè)務都適用這一原則。在有些業(yè)務場景中，大聚合可能是不可避免的。在這種情況下，如果想維護固定規(guī)則，是否采用聚合模式，需要權衡使用大聚合帶來的成本是否可以接受。聚合模式是一種設計模式，而非萬能的解決方案，在不適用的場景下強行應用聚合可能會導致收益不成正比。

聚合模式是為了解決復雜業(yè)務中的一致性問題，將具備固定規(guī)則的一組對象整存整取的一種方案。采用聚合模式的優(yōu)點在于比較簡單地就能實現(xiàn)固定規(guī)則約束，代價就是整存整取帶來的性能損失等問題。

五、【治療方案】

在案例中，盡管流水線各部分之間存在整體部分關系，通過對業(yè)務進行分析，我們確定了以下固定規(guī)則：

階段內(nèi)的步驟之間存在嚴格的順序依賴，因為下一個步驟通常依賴上一個步驟的產(chǎn)出物。因此，存在一個固定規(guī)則：某個步驟的執(zhí)行順序必須按照階段的步驟列表中的順序關系。階段質(zhì)量門禁和門禁項之間存在固定規(guī)則，即當在門禁項發(fā)生變更時，門禁版本也必須隨之更新門禁的版本有一定的業(yè)務含義（例如，門禁版本更新需要在界面上進行明確提示）。

圖片

整改后的聚合

因此，根據(jù)上述整改方案，原本的一個大聚合被拆分成了四個小聚合，每個聚合只包含少量實體。這種改動可以有效地降低聚合的規(guī)模，從而更好地平衡性能和業(yè)務一致性之間的關系。

六、【總結】

在領域驅(qū)動設計實踐中，聚合的劃分確實是一個難以把握的問題。聚合本身是一種有代價的模式，不合理的聚合劃分可能導致嚴重的問題，從而引發(fā)一系列疑問，例如“為什么使用DDD后仍然遇到各種問題？”聚合過大綜合癥是聚合劃分中的一種常見問題，當模型中出現(xiàn)寬聚合、深聚合或胖聚合時，我們需要警惕聚合過大綜合癥及其帶來的難以維護、犧牲可用性和性能損失等問題。

要解決這個問題，我們需要回顧聚合解決的核心問題：如何維護對象之間的固定規(guī)則。再次考慮聚合的劃分時，需要滿足兩個條件：整體-部分關系和實體間需要遵循的固定規(guī)則。當使用聚合模式的代價過大時，可以考慮其他方法來實現(xiàn)，例如通過鎖機制鎖定需要維護一致性的對象方法。

總之，在實踐DDD時，我們應該關注聚合的劃分和優(yōu)化，以確保在保持業(yè)務一致性和完整性的同時，避免因聚合過大導致的性能和可用性問題。在面臨聚合模式代價過大的情況時，可以靈活選擇其他方法來實現(xiàn)業(yè)務一致性和完整性。

關鍵詞：