作者 | 付施威

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

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

就診日期：2022年6月8日

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

診金：0元（免費(fèi)義診）

二、【患者主訴】

疑似問題設(shè)計

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

圖片

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

功能介紹：

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

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

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

圖片

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

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

引發(fā)問題

1. 認(rèn)知負(fù)載上升

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

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

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

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

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

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

三、【診斷】

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

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

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

1. 寬聚合

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

2. 深聚合

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

3. 胖聚合

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

圖片

聚合過大的三個征兆

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

四、【治療建議】

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

識別聚合的方法

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

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

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

1. 存在整體部分關(guān)系

當(dāng)某個Entity是另一個Entity的部分時，稱為整體部分關(guān)系。例如：

• 汽車輪胎是汽車的一部分
• 學(xué)生是班級的一部分
• 訂單行是訂單的一部分

2. 實體之間存在變更時需要遵守的固定規(guī)則（Invariants）

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

在計算機(jī)科學(xué)中，不變量是指在計算機(jī)程序執(zhí)行的某一階段始終為真的邏輯論斷。例如，循環(huán)不變量是一個條件，在一個循環(huán)的每個迭代開始和結(jié)束時都是真的。--- wiki <https://en.wikipedia.org/wiki/Invariant_(mathematics)>

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

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

圖片

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

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

大聚合都必須拆小么？

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

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

五、【治療方案】

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

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

圖片

整改后的聚合

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

六、【總結(jié)】

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

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

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