作者 | 付施威

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

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

就診日期：2022年6月8日

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

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

二、【患者主訴】

疑似問題設(shè)計(jì)

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

圖片

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

功能介紹：

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

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

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

圖片

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

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

引發(fā)問題

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

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

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

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

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

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

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

三、【診斷】

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

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

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

1. 寬聚合

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

2. 深聚合

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

3. 胖聚合

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

圖片

聚合過大的三個(gè)征兆

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

四、【治療建議】

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

識(shí)別聚合的方法

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

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

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

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

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

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

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

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

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

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

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

圖片

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

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

大聚合都必須拆小么？

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

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

五、【治療方案】

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

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

圖片

整改后的聚合

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

六、【總結(jié)】

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

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

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