本文作者為長沙.NET社區(qū)開發(fā)者微笑刺客，轉(zhuǎn)載已獲得作者授權(quán)。

前言

什么是領(lǐng)域，我習(xí)慣描述的是制藥領(lǐng)域、環(huán)境領(lǐng)域、建筑領(lǐng)域、金融領(lǐng)域等，而在領(lǐng)域內(nèi)，各種業(yè)務(wù)規(guī)則、業(yè)務(wù)知識(shí)盛行，如何有效的把控規(guī)則的變化，應(yīng)對(duì)復(fù)雜知識(shí)，有一個(gè)很關(guān)鍵的四字詞語，分而治之。分治法在很多場(chǎng)景下體現(xiàn)了其強(qiáng)大的作用力。領(lǐng)域本身很大，那就拆分，得到更小的領(lǐng)域，也即子域，如同遞歸調(diào)用一般，將一個(gè)復(fù)雜問題拆分單獨(dú)求解，而最終將解匯總得到復(fù)雜問題解。

怎么拆，拆成怎么樣合適，依據(jù)什么拆，這些在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中有了一套答案，雖然領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)不是銀彈，但可以說的上是一套極好的系統(tǒng)方法論或稱為架構(gòu)設(shè)計(jì)的方法論。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)常以戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)來將整個(gè)領(lǐng)域展現(xiàn)的淋漓盡致，其作用范圍既面向業(yè)務(wù)也面向技術(shù)。從戰(zhàn)略角度(個(gè)人更喜歡稱其為上帝視角)去規(guī)劃系統(tǒng)、劃分領(lǐng)域。而從戰(zhàn)術(shù)角度則從技術(shù)層面來指導(dǎo)我們?cè)撊绾稳ピO(shè)計(jì)。

戰(zhàn)略設(shè)計(jì)

戰(zhàn)略設(shè)計(jì)主要從高層俯視(上帝視角)我們的軟件系統(tǒng)，就如同玩即時(shí)戰(zhàn)略游戲般，可以一覽地圖全貌，以此來決定我們是要進(jìn)攻還是防守哪個(gè)方向，同樣，在軟件中我們也可以以此來劃分領(lǐng)域，確定權(quán)重方向。

統(tǒng)一語言

提煉領(lǐng)域知識(shí)，怎么個(gè)提煉法，千萬條羅馬路，各有各的看家本領(lǐng)。像事件風(fēng)暴方法，用例分析方法，用戶故事，甚至是開大會(huì)，各種討論會(huì)等，最終目的都是提煉出領(lǐng)域知識(shí)，而提煉過程中，達(dá)成描述上的一致性，包括系統(tǒng)目標(biāo)、系統(tǒng)范圍及系統(tǒng)所具有的功能。

這不是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)所獨(dú)有的，但卻是軟件開發(fā)中所必須的，為領(lǐng)域?qū)＜?、業(yè)務(wù)分析人員、編碼人員和測(cè)試人員等團(tuán)隊(duì)所有成員交流時(shí)構(gòu)建統(tǒng)一頻道。

領(lǐng)域/子域

領(lǐng)域拆分

對(duì)于領(lǐng)域這個(gè)概念，習(xí)慣性會(huì)想到制藥領(lǐng)域、環(huán)境領(lǐng)域、金融領(lǐng)域等這些概念，而領(lǐng)域本身所描述的是范圍，是如同現(xiàn)實(shí)世界般的復(fù)雜，無邊際。借助分治法，將問題逐級(jí)細(xì)分來降低業(yè)務(wù)和技術(shù)復(fù)雜度，將這復(fù)雜的世界劃分出清晰的邊界來，反過來控制著劃分后不那么復(fù)雜的世界，也既領(lǐng)域拆分出細(xì)化后的子領(lǐng)域。

子域劃分

在實(shí)際解決問題時(shí)，我們也習(xí)慣將問題拆分，而怎么拆，基于什么原則拆，可能會(huì)依據(jù)相關(guān)性，權(quán)重，甚至分類原則等，對(duì)于系統(tǒng)而言，會(huì)從架構(gòu)方面考慮，基礎(chǔ)設(shè)施考慮等，在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，更偏向基于業(yè)務(wù)拆分，降低業(yè)務(wù)復(fù)雜度，也分離技術(shù)實(shí)現(xiàn)的復(fù)雜度，依照業(yè)務(wù)拆分后的子領(lǐng)域，本身存在權(quán)重上的差異，依照重要性和功能劃分為三類，投資占比也就有所不同。

• 核心域：其所體現(xiàn)的是核心服務(wù)，是代表著產(chǎn)品的核心競(jìng)爭(zhēng)力。

• 支撐域：其所體現(xiàn)的是支撐服務(wù)，沒它不行，但又達(dá)不到核心的價(jià)值，圍繞著產(chǎn)品內(nèi)部所需要，但又不能單獨(dú)變更為第三方服務(wù)，即它不是一個(gè)通用的服務(wù)。

• 通用域：其所體現(xiàn)的中間件服務(wù)或第三方服務(wù)。本身可以通過現(xiàn)有的解決方案集成來完成的服務(wù)。

限界上下文

深入到一個(gè)子域中，又是一片小天地，在這天地中，卻又還是存在著因語義與語境上的差異，讓一些概念在這子域中顯得額外尷尬。在一個(gè)領(lǐng)域 / 子域中，我們會(huì)創(chuàng)建一個(gè)概念上的領(lǐng)域邊界，在這個(gè)邊界中，任何領(lǐng)域?qū)ο蠖贾槐硎咎囟ㄓ谠撨吔鐑?nèi)部的確切含義。這樣邊界便稱為限界上下文。

其本質(zhì)上是限界+上下文，引用到張逸老師的一句話

上下文（Context）其實(shí)是動(dòng)態(tài)的業(yè)務(wù)流程被邊界（Bounded）靜態(tài)切分的產(chǎn)物。

對(duì)于子域與上下文間的關(guān)系，看到很多書籍或是文章中所描述的都不一樣，這塊的爭(zhēng)論也沒有一個(gè)最終答案，個(gè)人更傾向于子域中劃分上下文，從拆分角度來講，這樣理解更加簡(jiǎn)單。

上下文識(shí)別

對(duì)于上下文的識(shí)別，沒有可遵循的標(biāo)準(zhǔn)可走，從不同的角度切入將會(huì)識(shí)別到不同的上下文，可從張逸老師的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐中窺之一二，以業(yè)務(wù)復(fù)雜度、管理復(fù)雜度和技術(shù)復(fù)雜度出發(fā)，面對(duì)這三個(gè)角度去依次分析，從業(yè)務(wù)視角、工作視角、應(yīng)用視角去識(shí)別，進(jìn)而識(shí)別出準(zhǔn)確的上下文，通過不斷的分析斟酌考慮，逐漸識(shí)別出符合當(dāng)前預(yù)期的上下文，如在實(shí)際操作環(huán)節(jié)發(fā)覺當(dāng)前上下文的設(shè)計(jì)顯得不那么合理，還可再進(jìn)行變動(dòng)、拆分上下文。

但需注意的一個(gè)是，我們識(shí)別上下文的目的是什么，是為了控制上下文，準(zhǔn)確的說是為了控制上下文的邊界、大小，是為了保住我們所守護(hù)的上下文不會(huì)因過度成長變大而奔潰，亦或因上下文過度縮減而失去價(jià)值，保證上下文內(nèi)一切的穩(wěn)定，上下文與上下文間交互的可用性，也或者是當(dāng)我們退出上下文時(shí)，交付出來的上下文是非常可觀的，而不是一個(gè)爛攤子。

上下文映射

規(guī)劃了這么多限界上下文，該如何穿針引線將這些上下文串起來便是一個(gè)問題了，用例場(chǎng)景的完整實(shí)現(xiàn)往往是由多個(gè)上下文的協(xié)作完成的，怎么去組織這些上下文，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)提到的幾種方式及軟件工程中常用模式。

• 合作關(guān)系：一榮俱榮，一損俱損。

• 共享內(nèi)核：上下文間共享領(lǐng)域?qū)嶓w。

• 客戶方-供應(yīng)方：下游客戶依賴于上游供應(yīng)方。

• 遵奉者：下游客戶順應(yīng)上游供應(yīng)方。

• 各行其道：沒有關(guān)系的關(guān)系，相互隔離。

• 防腐層：在下游上下文與上游間增加一道屏障，以此來隔絕與上游的直接交互保護(hù)下游。

• 開放主機(jī)服務(wù)：在上游與下游上下文間增加一道協(xié)議，以此來規(guī)范下游對(duì)上游的集成。

• 已發(fā)布語言：發(fā)布方上下文發(fā)布一份包含豐富文檔的信息交換語言，消費(fèi)方上下文翻譯并使用。

這些模式其本質(zhì)是為了協(xié)作，為了滿足用例場(chǎng)景下對(duì)多個(gè)限界上下文的調(diào)用，通過上下文映射圖，可以清楚知曉運(yùn)行邏輯。為了實(shí)現(xiàn)上下文映射，簡(jiǎn)單講就是如何將兩個(gè)上下文連貫起來，常借助的方式是諸如 RPC、HTTP、消息隊(duì)列等，依照上下文間映射類型，挑選一件趁手的工具。

分層架構(gòu)

我們通常喜歡對(duì)各種事情歸納總結(jié)，如文章的層次分明，如建筑結(jié)構(gòu)高低有序、疏密有致，給人一種各處所關(guān)注的信息視角不同，而組合起來顯得如此美妙。軟件中同樣運(yùn)用著分層來隔離關(guān)注點(diǎn)，以此來隔離每層的演進(jìn)速率。

當(dāng)我們考慮限界上下文時(shí)，不僅需要去考慮其內(nèi)部的領(lǐng)域設(shè)計(jì)，還得從其應(yīng)用邊界本身考慮，限界上下文是屬于架構(gòu)設(shè)計(jì)層次，主要針對(duì)的是后端架構(gòu)層次的垂直切分，按照經(jīng)典 DDD 的分層結(jié)構(gòu)來看，共分為如下四層：

• User Interface 為用戶界面層，向用戶展示信息和傳入用戶命令。這里指的用戶不單單只使用用戶界面的人，也可能是外部系統(tǒng)，諸如用例中的參與者。

• Application 為應(yīng)用層，用來協(xié)調(diào)應(yīng)用的活動(dòng)，不包含業(yè)務(wù)邏輯，通過編排領(lǐng)域模型，包括領(lǐng)域?qū)ο蠹邦I(lǐng)域服務(wù)，使它們互相協(xié)作。不保留業(yè)務(wù)對(duì)象的狀態(tài)，但它保有應(yīng)用任務(wù)的進(jìn)度狀態(tài)。

• Domain 為領(lǐng)域?qū)?，?fù)責(zé)表達(dá)業(yè)務(wù)概念，業(yè)務(wù)狀態(tài)信息以及業(yè)務(wù)規(guī)則。盡管保存業(yè)務(wù)狀態(tài)的技術(shù)細(xì)節(jié)是由基礎(chǔ)設(shè)施層實(shí)現(xiàn)的，但是反映業(yè)務(wù)情況的狀態(tài)是由本層控制并且使用的。領(lǐng)域?qū)邮菢I(yè)務(wù)軟件的核心，領(lǐng)域模型位于這一層。

• Infrastructure 為基礎(chǔ)實(shí)施層，提供公共的基礎(chǔ)設(shè)施組件，如持久化機(jī)制、消息管道的讀取寫入、文件服務(wù)的讀取寫入、調(diào)用郵件服務(wù)、對(duì)外部系統(tǒng)的調(diào)用等等。

值得注意的是，給定的分層方式僅僅是邏輯上的分層，而對(duì)于實(shí)際的物理分層，卻又有所不同，但遵守一個(gè)前提為好，即限界上下文的邊界高于分層的邊界。諸如如下兩種開發(fā)中常見的代碼組織方式，都可見到。一種是基于技術(shù)分層，而另一種更偏向基于業(yè)務(wù)分層。

方式一

方式二

- productcontext
  - application
  - domain
  - infrastructure
- ordercontext
  - application
  - domain
  - infrastructure

具體采用哪種方式，并沒有強(qiáng)制要求，無論代碼組織結(jié)構(gòu)是否表達(dá)了層的概念，都需要充分理解分層的意義，并使得整個(gè)代碼結(jié)構(gòu)在架構(gòu)上要吻合分層架構(gòu)的理念。

戰(zhàn)術(shù)設(shè)計(jì)

相比于戰(zhàn)略設(shè)計(jì)的怎么規(guī)劃，戰(zhàn)術(shù)設(shè)計(jì)更側(cè)重于怎么執(zhí)行，詳細(xì)的設(shè)計(jì)和編碼。

聚合

在認(rèn)識(shí)聚合前，我們得對(duì)類再次回顧，類是作為我們開發(fā)中的最小單元，一切以類構(gòu)建，而在上下文的視角中，聚合成了最小概念，包裝了一組高度相關(guān)的對(duì)象，上下文內(nèi)以聚合為最小單元，以此來保證聚合邊界。又將分而治之的思想融入到了限界上下文的內(nèi)部。

聚合本身是由一個(gè)或多個(gè)實(shí)體及值對(duì)象組成，其中一個(gè)實(shí)體作為聚合根。管理著內(nèi)部關(guān)聯(lián)的實(shí)體與值對(duì)象，對(duì)外代表著聚合，外部來訪者僅可通過聚合根進(jìn)行訪問。

對(duì)于聚合圖的畫法，或許因人而異，我更加傾向于用矩形代表實(shí)體，橢圓代表值對(duì)象，用 UML 類圖中的組合-聚合箭頭來表示其雙方間的關(guān)系。

需要注意的是，此處的聚合不要與 UML 類圖中的聚合等同起來，兩者含義并不相同。

實(shí)體

對(duì)于實(shí)體來講，這個(gè)概念對(duì)于我們并不陌生，擁有者唯一的身份標(biāo)識(shí)符，內(nèi)含屬性作為該實(shí)體的靜態(tài)特征，作為聚合所擁有的領(lǐng)域知識(shí)，擁有著與自身相關(guān)的領(lǐng)域行為。

值對(duì)象

對(duì)于值對(duì)象，我傾向于將它理解為，基礎(chǔ)類型之延伸，既能封裝基礎(chǔ)類型，又能約束內(nèi)部屬性間關(guān)系，還能擁有著自身的領(lǐng)域行為，而與實(shí)體的區(qū)別是，沒有唯一身份標(biāo)識(shí)，盡管帶來了持久化的一些問題，但還是存在解決方案。以 DateTime 理解值對(duì)象最好不過了，DateTime 內(nèi)部的自身約束保證了，每一次變動(dòng)的 DateTime 都是最新的，當(dāng)我們想在 2 月 28 日加 1，這便要依靠 DateTime 中的行為去約束內(nèi)部的屬性。

聚合劃分

經(jīng)統(tǒng)一語言與業(yè)務(wù)分析階段，借助一系列如事件風(fēng)暴、用例分析法、名次動(dòng)詞法、四色建模法等活動(dòng)后，獲得了一系列相關(guān)聯(lián)的對(duì)象?；蚩尚纬梢粡堼嫶蟮膶?duì)象關(guān)聯(lián)圖。

如不考慮聚合的劃分，我們依照以往的思路便是創(chuàng)建一大堆表，運(yùn)用三范式或是依靠程序去保證數(shù)據(jù)的一致性不運(yùn)用主外鍵。然后瘋狂擼碼，CRUD 好不快活。

而隨著業(yè)務(wù)的逐漸擴(kuò)張，這當(dāng)初的想法已有點(diǎn)吃力了，如同樹苗逐漸成長，枝葉也逐漸增多。借助枝干我們可以分清葉子的歸屬，而對(duì)象網(wǎng)中呢，變得錯(cuò)綜復(fù)雜了，也就隱約有了大泥球的征兆。

借助劃分聚合的一些方法，將其規(guī)整化。將原有復(fù)雜的對(duì)象圖拆分成可控制的小型對(duì)象圖。

• 保持單一導(dǎo)航方向，解除雙向依賴，保持依賴簡(jiǎn)單。

• 保持聚合設(shè)計(jì)的小巧

• 聚合內(nèi)的業(yè)務(wù)規(guī)則一致性

• 通過聚合標(biāo)識(shí)符引用其他聚合

• 聚合與協(xié)作聚合間因業(yè)務(wù)場(chǎng)景、進(jìn)程邊界等因素影響，可依照?qǐng)鼍笆褂脧?qiáng)一致性或是最終一致性。

如上的對(duì)象圖依照關(guān)系的強(qiáng)弱，關(guān)系的主與次進(jìn)行了聚合劃分，或許得出的部分聚合存在不合理處，可再調(diào)整其邊界。

聚合協(xié)作

聚合與協(xié)作聚合之間依照聚合根實(shí)體的唯一標(biāo)識(shí)符進(jìn)行關(guān)聯(lián)，而不是通過依靠協(xié)作聚合的引用實(shí)例來完成。保持這個(gè)原則有助于保持聚合之間的邊界并避免加載不必要的對(duì)象。如我們常習(xí)慣上將關(guān)聯(lián)的集合對(duì)象寫入到類中，然后在倉儲(chǔ)使用時(shí)，通過 EF 加載導(dǎo)航屬性，以此方便直接加載關(guān)聯(lián)聚合數(shù)據(jù)。

如 Order 和 OrderItem，當(dāng)我們考慮將其作為一個(gè)聚合時(shí)，這么使用，是可以的，但是不能說跨聚合也這么用著，如 Enterprise 和 Order，劃分時(shí)我們更加傾向于劃分為兩個(gè)聚合，遵循保持聚合原則中，引用聚合根的 Id 這一原則，這將改善聚合的邊界使其更加清晰，控制更加妥當(dāng)。

//多聚合間不建議這么用
public class Order : AggregateRoot
{
    //遵循聚合原則引用 Enterprice 聚合根 Id,而不是實(shí)例
    public int EnterpriceId {get; set;}
    //public virtual Enterprice Enterprice { get; set; }
    //...
}

考慮到多聚合的協(xié)作，便要了解下聚合的首要原則，即在一次事務(wù)中，只能更改一個(gè)聚合的狀態(tài)，因此當(dāng)涉及到多個(gè)聚合協(xié)作時(shí)，如創(chuàng)建訂單完畢，需要往庫存中某一商品數(shù)量減少時(shí)，訂單本身一般會(huì)有商品聚合的標(biāo)識(shí)，借助這個(gè)標(biāo)識(shí)，通過領(lǐng)域事件或是集成事件方式，事件接收方將相關(guān)聯(lián)的庫存聚合調(diào)用起來，以此達(dá)到多個(gè)聚合間的協(xié)作。
又或者考慮到，需要調(diào)用商品的信息以使得當(dāng)前訂單中商品信息更加豐富，可通過防腐層調(diào)用商品所在上下文遠(yuǎn)程服務(wù)或是應(yīng)用服務(wù)，最終本質(zhì)上是調(diào)用商品聚合中的信息豐富到訂單中，也使得多個(gè)聚合完成協(xié)作。

應(yīng)用服務(wù)

作為限界上下文對(duì)外的門戶，也即是外觀模式的體現(xiàn)。通過用例分析識(shí)別出來的用例在此處一一對(duì)應(yīng)存在著，對(duì)外提供統(tǒng)一接口，以此滿足完整用例場(chǎng)景所需的功能。在應(yīng)用服務(wù)內(nèi)部，通過編排領(lǐng)域模型對(duì)象來完成用例的功能，自身并不包含領(lǐng)域邏輯，但包含著應(yīng)用邏輯。

可借鑒整潔架構(gòu)的經(jīng)典圖例來看應(yīng)用層本身的職責(zé)所在，Use Case(用例層)-Application Business Rules，雖然是依靠著領(lǐng)域模型對(duì)象才完成的（具體是編排領(lǐng)域模型對(duì)象所具有的領(lǐng)域行為），卻也說明了應(yīng)用服務(wù)承擔(dān)著的是用例的職責(zé)。

需要注意的是，應(yīng)用服務(wù)的職責(zé)不僅限于編排領(lǐng)域模型對(duì)象，還需要控制著橫切關(guān)注點(diǎn)，如驗(yàn)證、日志、事物等的管理。

如上，事務(wù)、認(rèn)證、請(qǐng)求參數(shù)校驗(yàn)(Dto 內(nèi))，協(xié)調(diào)領(lǐng)域模型對(duì)象和基礎(chǔ)設(shè)施服務(wù)，這是應(yīng)用服務(wù)的職責(zé)，當(dāng)然也不僅限于這些職責(zé)。

領(lǐng)域服務(wù)

當(dāng)我們考慮領(lǐng)域邏輯時(shí)，首先想到的應(yīng)該是實(shí)體與值對(duì)象中具有的領(lǐng)域邏輯，而有些場(chǎng)景下，實(shí)體與值對(duì)象無法承載這些領(lǐng)域行為，如對(duì)多個(gè)領(lǐng)域?qū)ο笞鳛檩斎耄M(jìn)行計(jì)算并產(chǎn)出一個(gè)值對(duì)象；又或是需要將操作成集合化的聚合，如在 Supplier 下需要將所有 Order 中的單價(jià)匯總，而本身 Supplier 和 Order 是為兩個(gè)聚合，若考慮借助 Order 去完成該業(yè)務(wù)操作，不太妥當(dāng)，在此場(chǎng)景下，可通過領(lǐng)域服務(wù)來承載著這些領(lǐng)域行為。

領(lǐng)域服務(wù)存在如下特征：

• 執(zhí)行一個(gè)顯著的業(yè)務(wù)操作過程

• 對(duì)領(lǐng)域?qū)ο筮M(jìn)行轉(zhuǎn)換

• 需要使用多個(gè)聚合內(nèi)的實(shí)體和值對(duì)象編排業(yè)務(wù)邏輯

• 領(lǐng)域行為需要訪問外部資源

雖說領(lǐng)域服務(wù)能夠承載領(lǐng)域邏輯，卻不能說將所有的領(lǐng)域邏輯都往里塞，如此，導(dǎo)致領(lǐng)域?qū)ο筘氀?。只有?dāng)實(shí)體與值對(duì)象承載不住或是本身并不屬于實(shí)體或值對(duì)象的職責(zé)內(nèi)時(shí)，才考慮領(lǐng)域服務(wù)來承載，領(lǐng)域服務(wù)是一種妥協(xié)的結(jié)果，并不是說領(lǐng)域服務(wù)越多越好。

值對(duì)象（Value Object）→ 實(shí)體（Entity）→ 領(lǐng)域服務(wù)（Domain Service）

如下場(chǎng)景，創(chuàng)建 Invoice，存在幾條業(yè)務(wù)規(guī)則，相應(yīng) Order 的狀態(tài)需已完成，并且對(duì)應(yīng)的 Supplier 提供財(cái)月信息，這就需要多個(gè)聚合的協(xié)作，在領(lǐng)域服務(wù)編排這些領(lǐng)域?qū)ο竽Ｐ图巴ㄟ^調(diào)用外部服務(wù)網(wǎng)關(guān)，完成業(yè)務(wù)邏輯。

在應(yīng)用服務(wù)中，通過調(diào)用聚合及領(lǐng)域服務(wù)，完成這一創(chuàng)建 Invoice 的用例。

[UnitOfWork]
[Authorize(PermissionNames.Invoice_Create)]
public async Task CreateInvoice(CreateInvoiceDto input)
{
    await _invoiceManager.ValidCheck(input.orderId, input.SupplierId);
    var invoice = Invoice.Create(input.Name, input.Description)
        .SetOrder(input.OrderId);
    await _invoiceManager.SetFinanceMonth(invoice, input.SupplierId);
    await _invoiceRepository.InsertAsync(invoice);
    await _appNotifier.NewInvoiceAsync();
}

借助領(lǐng)域服務(wù)，以此來完成多聚合間的協(xié)作，通過應(yīng)用服務(wù)編排領(lǐng)域模型對(duì)象，完成一個(gè)業(yè)務(wù)用例。

領(lǐng)域事件

在軟件開發(fā)中，事件早已被我們所熟悉，一個(gè)按鈕按下，產(chǎn)生中斷事件，一個(gè)回車，前端頁面有偵聽事件，在事件風(fēng)暴建模活動(dòng)中，事件也是作為領(lǐng)域建模的突破口，事件的重要性不言而喻。其本質(zhì)是發(fā)生的事實(shí)到引發(fā)了相關(guān)事情，在這其中的傳遞的信息便是事件的內(nèi)容。就如同貓叫了，引發(fā)著老鼠跑了，主人醒了，其中的事件便是貓叫了，而該事件是貓執(zhí)行叫的動(dòng)作后的結(jié)果。

在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，最開始的版本中并沒有領(lǐng)域事件的概念，在 DDD 社區(qū)對(duì)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的內(nèi)容不斷的充實(shí)中，引入了領(lǐng)域事件。領(lǐng)域事件的命名遵循英語中的“名詞 + 動(dòng)詞過去分詞”格式，如，提交訂單后發(fā)布的 OrderCreated 事件，訂單完成后 OrderCompleted 事件，用以表示我們建模的領(lǐng)域中發(fā)生過的一件事情，也符合著事件本身是具有時(shí)間特征。

對(duì)于領(lǐng)域事件本身，依據(jù)各層的使用方式及面對(duì)的目標(biāo)不同，劃分出兩種事件類型，領(lǐng)域事件與應(yīng)用事件(或集成事件)，應(yīng)用事件側(cè)重于應(yīng)用層的使用，而領(lǐng)域事件沿用原領(lǐng)域事件的稱呼，更偏向于領(lǐng)域?qū)?。而又?yīng)側(cè)重點(diǎn)不同，又有著不同的使用方式，如領(lǐng)域事件更多的是從領(lǐng)域模型中發(fā)布，其最終接收者為當(dāng)前聚合所在限界上下文，而應(yīng)用事件更為廣闊，從應(yīng)用層發(fā)布，其接收者為當(dāng)前上下文或是其他上下文。

基于限界上下文間采用的部署方式不同，也存在著不同的通信方式，如整個(gè)應(yīng)用程序?yàn)閱误w，則所有上下文在同一個(gè)進(jìn)程內(nèi)，則上下文間事件交互時(shí)所采用的可以是進(jìn)程內(nèi)的事件總線，或是進(jìn)程間使用的消息隊(duì)列，而當(dāng)在進(jìn)程間時(shí)，就不得不使用進(jìn)程間的消息隊(duì)列了。

由于 DDD 中遵循一個(gè)用例對(duì)應(yīng)一個(gè)事務(wù)，在一個(gè)事務(wù)中更新一個(gè)聚合，因此對(duì)于實(shí)際場(chǎng)景中需要變更多個(gè)聚合下，我們常通過編排方式調(diào)用其他聚合的服務(wù)，這不可避免的加重了對(duì)其他服務(wù)的依賴，借助領(lǐng)域事件，則可以很方便的降低這種耦合，同時(shí)對(duì)于多個(gè)聚合的變更操作，由單個(gè)聚合的事務(wù)變成了多個(gè)聚合的事務(wù)，又依照實(shí)際影響的聚合情況，有著不同的處理方式，如多個(gè)協(xié)作的聚合為同一上下文內(nèi)時(shí)，可通過強(qiáng)一致性去保證數(shù)據(jù)一致性，而處于多個(gè)限界上下文間的聚合時(shí)，則可依照最終一致性保證數(shù)據(jù)的一致性。

領(lǐng)域事件主要用途有：

• 從事件角度豐富了領(lǐng)域模型

• 保證聚合間的數(shù)據(jù)一致性

• 實(shí)現(xiàn)事件事件溯源和 CQRS 等

• 限界上下文間集成(發(fā)布訂閱模式)

資源庫

在剛接觸資源庫(Repository)時(shí)，第一反應(yīng)便是這就是個(gè) DAO 層，訪問數(shù)據(jù)庫，然后吧啦吧啦，但是，當(dāng)接觸的越久，越發(fā)認(rèn)識(shí)到第一反應(yīng)是錯(cuò)的，資源庫更多的是對(duì)資源的管理，而不僅僅是數(shù)據(jù)庫中的數(shù)據(jù)，數(shù)據(jù)庫可以作為資源的一部分，但不是全部，我們習(xí)慣將對(duì)外部系統(tǒng)的調(diào)用稱為外部資源的獲取，這也是將外部系統(tǒng)作為資源的一部分。

對(duì)于聚合來講，資源庫的作用是負(fù)責(zé)將聚合持久化到數(shù)據(jù)庫的(通常是持久化到數(shù)據(jù)庫)，并且由于聚合根負(fù)責(zé)維持聚合的生命周期，也就使得應(yīng)考慮僅聚合根才應(yīng)該擁有資源庫，這也是與 DAO 層不同的地方。

在分層設(shè)計(jì)時(shí)，考慮將資源庫的抽象劃分到領(lǐng)域?qū)?，屬于領(lǐng)域模型對(duì)象的一部分，如同設(shè)計(jì)防腐層的抽象網(wǎng)關(guān)般，資源庫的抽象作為特殊的網(wǎng)關(guān)，當(dāng)在應(yīng)用層或是領(lǐng)域?qū)又胁僮髻Y源庫抽象時(shí)，將資源庫作為管理聚合狀態(tài)的工具，可以忽視基礎(chǔ)設(shè)施層中對(duì)資源庫的具體實(shí)現(xiàn)。而在考慮基礎(chǔ)設(shè)施層中具體實(shí)現(xiàn)時(shí)，可根據(jù)需要選擇適合的工具，以此來管理和操作資源。

工廠

聚合從 0 到 1 的過程，可以通過多種途徑創(chuàng)建，一般來講，我們開發(fā)中常直接實(shí)例化或是反射實(shí)例化，而對(duì)于聚合來講，整個(gè)聚合是一個(gè)整體，命運(yùn)共同體，并且由聚合根掌握聚合的生命周期。通常，我們可以借助幾種方式來創(chuàng)建聚合，組裝聚合，在創(chuàng)建過程中封裝業(yè)務(wù)邏輯。

• 聚合自身擔(dān)任工廠，在聚合根中實(shí)現(xiàn) Factory 方法

• 獨(dú)立的 Factory 類，用于有一定復(fù)雜度的創(chuàng)建過程，或者創(chuàng)建邏輯不適合放在聚合根上

• 借助其他聚合來創(chuàng)建，其他聚合擔(dān)任工廠角色

• 借助構(gòu)建者模式靈活組裝聚合

聚合根的創(chuàng)建有多種方式，依據(jù)聚合內(nèi)掌握知識(shí)的多少與創(chuàng)建邏輯的需要可靈活選擇。

如借助構(gòu)建者模式，通過拆分許多小的方法，將過多的參數(shù)拆分，以此避免一個(gè)創(chuàng)建方法參數(shù)中滿屏都是參數(shù)的情況，需要考慮吧拆分的方法需要滿足業(yè)務(wù)一致性，如內(nèi)部的一些屬性間有約束條件下，需要?jiǎng)澐值揭粋€(gè)方法中，以維持一致性或不變性。

學(xué)無止境

從2004年領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)到現(xiàn)在已經(jīng)有17年時(shí)間了，并且在其中還有諸如六邊形架構(gòu)，洋蔥架構(gòu)，整潔架構(gòu)等的出現(xiàn)，考慮的側(cè)重點(diǎn)不同，衍生著大量的新概念，也不斷地完善著領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的思想。在學(xué)習(xí)與理解領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，總會(huì)有新的東西改變我們以往的思想，見到的越多，越發(fā)覺認(rèn)識(shí)的越少，這或許也是學(xué)起來有點(diǎn)阻力的原因吧。

參考

1. 《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》- Vaughn Verno

2. 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐》- 張逸

3. 《軟件架構(gòu)編年史》- herbertograca

4. 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)現(xiàn)之路 - 滕云

5. 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)編碼實(shí)踐 - 滕云

6. Package by component and architecturally-aligned testing - Simon

2021-01-18,望技術(shù)有成后能回來看見自己的腳步