一文看懂領(lǐng)域驅(qū)動設(shè)計！
本文作者為長沙.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ù)知識盛行，如何有效的把控規(guī)則的變化，應(yīng)對復(fù)雜知識，有一個很關(guān)鍵的四字詞語，分而治之。分治法在很多場景下體現(xiàn)了其強(qiáng)大的作用力。領(lǐng)域本身很大，那就拆分，得到更小的領(lǐng)域，也即子域，如同遞歸調(diào)用一般，將一個復(fù)雜問題拆分單獨(dú)求解，而最終將解匯總得到復(fù)雜問題解。
怎么拆，拆成怎么樣合適，依據(jù)什么拆，這些在領(lǐng)域驅(qū)動設(shè)計中有了一套答案，雖然領(lǐng)域驅(qū)動設(shè)計不是銀彈，但可以說的上是一套極好的系統(tǒng)方法論或稱為架構(gòu)設(shè)計的方法論。
領(lǐng)域驅(qū)動設(shè)計常以戰(zhàn)略設(shè)計與戰(zhàn)術(shù)設(shè)計來將整個領(lǐng)域展現(xiàn)的淋漓盡致，其作用范圍既面向業(yè)務(wù)也面向技術(shù)。從戰(zhàn)略角度(個人更喜歡稱其為上帝視角)去規(guī)劃系統(tǒng)、劃分領(lǐng)域。而從戰(zhàn)術(shù)角度則從技術(shù)層面來指導(dǎo)我們該如何去設(shè)計。
戰(zhàn)略設(shè)計
戰(zhàn)略設(shè)計主要從高層俯視(上帝視角)我們的軟件系統(tǒng)，就如同玩即時戰(zhàn)略游戲般，可以一覽地圖全貌，以此來決定我們是要進(jìn)攻還是防守哪個方向，同樣，在軟件中我們也可以以此來劃分領(lǐng)域，確定權(quán)重方向。
統(tǒng)一語言
提煉領(lǐng)域知識，怎么個提煉法，千萬條羅馬路，各有各的看家本領(lǐng)。像事件風(fēng)暴方法，用例分析方法，用戶故事，甚至是開大會，各種討論會等，最終目的都是提煉出領(lǐng)域知識，而提煉過程中，達(dá)成描述上的一致性，包括系統(tǒng)目標(biāo)、系統(tǒng)范圍及系統(tǒng)所具有的功能。
這不是領(lǐng)域驅(qū)動設(shè)計所獨(dú)有的，但卻是軟件開發(fā)中所必須的，為領(lǐng)域?qū)＜摇I(yè)務(wù)分析人員、編碼人員和測試人員等團(tuán)隊所有成員交流時構(gòu)建統(tǒng)一頻道。
領(lǐng)域/子域
領(lǐng)域拆分
對于領(lǐng)域這個概念，習(xí)慣性會想到制藥領(lǐng)域、環(huán)境領(lǐng)域、金融領(lǐng)域等這些概念，而領(lǐng)域本身所描述的是范圍，是如同現(xiàn)實(shí)世界般的復(fù)雜，無邊際。借助分治法，將問題逐級細(xì)分來降低業(yè)務(wù)和技術(shù)復(fù)雜度，將這復(fù)雜的世界劃分出清晰的邊界來，反過來控制著劃分后不那么復(fù)雜的世界，也既領(lǐng)域拆分出細(xì)化后的子領(lǐng)域。
子域劃分
在實(shí)際解決問題時，我們也習(xí)慣將問題拆分，而怎么拆，基于什么原則拆，可能會依據(jù)相關(guān)性，權(quán)重，甚至分類原則等，對于系統(tǒng)而言，會從架構(gòu)方面考慮，基礎(chǔ)設(shè)施考慮等，在領(lǐng)域驅(qū)動設(shè)計中，更偏向基于業(yè)務(wù)拆分，降低業(yè)務(wù)復(fù)雜度，也分離技術(shù)實(shí)現(xiàn)的復(fù)雜度，依照業(yè)務(wù)拆分后的子領(lǐng)域，本身存在權(quán)重上的差異，依照重要性和功能劃分為三類，投資占比也就有所不同。
核心域：其所體現(xiàn)的是核心服務(wù)，是代表著產(chǎn)品的核心競爭力。
支撐域：其所體現(xiàn)的是支撐服務(wù)，沒它不行，但又達(dá)不到核心的價值，圍繞著產(chǎn)品內(nèi)部所需要，但又不能單獨(dú)變更為第三方服務(wù)，即它不是一個通用的服務(wù)。
通用域：其所體現(xiàn)的中間件服務(wù)或第三方服務(wù)。本身可以通過現(xiàn)有的解決方案集成來完成的服務(wù)。
限界上下文
深入到一個子域中，又是一片小天地，在這天地中，卻又還是存在著因語義與語境上的差異，讓一些概念在這子域中顯得額外尷尬。在一個領(lǐng)域 / 子域中，我們會創(chuàng)建一個概念上的領(lǐng)域邊界，在這個邊界中，任何領(lǐng)域?qū)ο蠖贾槐硎咎囟ㄓ谠撨吔鐑?nèi)部的確切含義。這樣邊界便稱為限界上下文。
其本質(zhì)上是限界+上下文，引用到張逸老師的一句話
上下文（Context）其實(shí)是動態(tài)的業(yè)務(wù)流程被邊界（Bounded）靜態(tài)切分的產(chǎn)物。
對于子域與上下文間的關(guān)系，看到很多書籍或是文章中所描述的都不一樣，這塊的爭論也沒有一個最終答案，個人更傾向于子域中劃分上下文，從拆分角度來講，這樣理解更加簡單。
上下文識別
對于上下文的識別，沒有可遵循的標(biāo)準(zhǔn)可走，從不同的角度切入將會識別到不同的上下文，可從張逸老師的領(lǐng)域驅(qū)動設(shè)計實(shí)踐中窺之一二，以業(yè)務(wù)復(fù)雜度、管理復(fù)雜度和技術(shù)復(fù)雜度出發(fā)，面對這三個角度去依次分析，從業(yè)務(wù)視角、工作視角、應(yīng)用視角去識別，進(jìn)而識別出準(zhǔn)確的上下文，通過不斷的分析斟酌考慮，逐漸識別出符合當(dāng)前預(yù)期的上下文，如在實(shí)際操作環(huán)節(jié)發(fā)覺當(dāng)前上下文的設(shè)計顯得不那么合理，還可再進(jìn)行變動、拆分上下文。
但需注意的一個是，我們識別上下文的目的是什么，是為了控制上下文，準(zhǔn)確的說是為了控制上下文的邊界、大小，是為了保住我們所守護(hù)的上下文不會因過度成長變大而奔潰，亦或因上下文過度縮減而失去價值，保證上下文內(nèi)一切的穩(wěn)定，上下文與上下文間交互的可用性，也或者是當(dāng)我們退出上下文時，交付出來的上下文是非?？捎^的，而不是一個爛攤子。
上下文映射
規(guī)劃了這么多限界上下文，該如何穿針引線將這些上下文串起來便是一個問題了，用例場景的完整實(shí)現(xiàn)往往是由多個上下文的協(xié)作完成的，怎么去組織這些上下文，領(lǐng)域驅(qū)動設(shè)計提到的幾種方式及軟件工程中常用模式。
合作關(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ī)范下游對上游的集成。
已發(fā)布語言：發(fā)布方上下文發(fā)布一份包含豐富文檔的信息交換語言，消費(fèi)方上下文翻譯并使用。
這些模式其本質(zhì)是為了協(xié)作，為了滿足用例場景下對多個限界上下文的調(diào)用，通過上下文映射圖，可以清楚知曉運(yùn)行邏輯。為了實(shí)現(xiàn)上下文映射，簡單講就是如何將兩個上下文連貫起來，常借助的方式是諸如 RPC、HTTP、消息隊列等，依照上下文間映射類型，挑選一件趁手的工具。
分層架構(gòu)
我們通常喜歡對各種事情歸納總結(jié)，如文章的層次分明，如建筑結(jié)構(gòu)高低有序、疏密有致，給人一種各處所關(guān)注的信息視角不同，而組合起來顯得如此美妙。軟件中同樣運(yùn)用著分層來隔離關(guān)注點(diǎn)，以此來隔離每層的演進(jìn)速率。
當(dāng)我們考慮限界上下文時，不僅需要去考慮其內(nèi)部的領(lǐng)域設(shè)計，還得從其應(yīng)用邊界本身考慮，限界上下文是屬于架構(gòu)設(shè)計層次，主要針對的是后端架構(gòu)層次的垂直切分，按照經(jīng)典 DDD 的分層結(jié)構(gòu)來看，共分為如下四層：
User Interface 為用戶界面層，向用戶展示信息和傳入用戶命令。這里指的用戶不單單只使用用戶界面的人，也可能是外部系統(tǒng)，諸如用例中的參與者。
Application 為應(yīng)用層，用來協(xié)調(diào)應(yīng)用的活動，不包含業(yè)務(wù)邏輯，通過編排領(lǐng)域模型，包括領(lǐng)域?qū)ο蠹邦I(lǐng)域服務(wù)，使它們互相協(xié)作。不保留業(yè)務(wù)對象的狀態(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ù)、對外部系統(tǒng)的調(diào)用等等。
值得注意的是，給定的分層方式僅僅是邏輯上的分層，而對于實(shí)際的物理分層，卻又有所不同，但遵守一個前提為好，即限界上下文的邊界高于分層的邊界。諸如如下兩種開發(fā)中常見的代碼組織方式，都可見到。一種是基于技術(shù)分層，而另一種更偏向基于業(yè)務(wù)分層。
方式一
- application
- productcontext
- ordercontext
- ...
- domain
- productcontext
- ordercontext
- ...
- infrastructure
- productcontext
- ordercontext
- ...
方式二
- productcontext
- application
- domain
- infrastructure
- ordercontext
- application
- domain
- infrastructure
具體采用哪種方式，并沒有強(qiáng)制要求，無論代碼組織結(jié)構(gòu)是否表達(dá)了層的概念，都需要充分理解分層的意義，并使得整個代碼結(jié)構(gòu)在架構(gòu)上要吻合分層架構(gòu)的理念。
戰(zhàn)術(shù)設(shè)計
相比于戰(zhàn)略設(shè)計的怎么規(guī)劃，戰(zhàn)術(shù)設(shè)計更側(cè)重于怎么執(zhí)行，詳細(xì)的設(shè)計和編碼。
聚合
在認(rèn)識聚合前，我們得對類再次回顧，類是作為我們開發(fā)中的最小單元，一切以類構(gòu)建，而在上下文的視角中，聚合成了最小概念，包裝了一組高度相關(guān)的對象，上下文內(nèi)以聚合為最小單元，以此來保證聚合邊界。又將分而治之的思想融入到了限界上下文的內(nèi)部。
聚合本身是由一個或多個實(shí)體及值對象組成，其中一個實(shí)體作為聚合根。管理著內(nèi)部關(guān)聯(lián)的實(shí)體與值對象，對外代表著聚合，外部來訪者僅可通過聚合根進(jìn)行訪問。
對于聚合圖的畫法，或許因人而異，我更加傾向于用矩形代表實(shí)體，橢圓代表值對象，用 UML 類圖中的組合-聚合箭頭來表示其雙方間的關(guān)系。
需要注意的是，此處的聚合不要與 UML 類圖中的聚合等同起來，兩者含義并不相同。
實(shí)體
對于實(shí)體來講，這個概念對于我們并不陌生，擁有者唯一的身份標(biāo)識符，內(nèi)含屬性作為該實(shí)體的靜態(tài)特征，作為聚合所擁有的領(lǐng)域知識，擁有著與自身相關(guān)的領(lǐng)域行為。
值對象
對于值對象，我傾向于將它理解為，基礎(chǔ)類型之延伸，既能封裝基礎(chǔ)類型，又能約束內(nèi)部屬性間關(guān)系，還能擁有著自身的領(lǐng)域行為，而與實(shí)體的區(qū)別是，沒有唯一身份標(biāo)識，盡管帶來了持久化的一些問題，但還是存在解決方案。以 DateTime 理解值對象最好不過了，DateTime 內(nèi)部的自身約束保證了，每一次變動的 DateTime 都是最新的，當(dāng)我們想在 2 月 28 日加 1，這便要依靠 DateTime 中的行為去約束內(nèi)部的屬性。
聚合劃分
經(jīng)統(tǒng)一語言與業(yè)務(wù)分析階段，借助一系列如事件風(fēng)暴、用例分析法、名次動詞法、四色建模法等活動后，獲得了一系列相關(guān)聯(lián)的對象?；蚩尚纬梢粡堼嫶蟮膶ο箨P(guān)聯(lián)圖。
如不考慮聚合的劃分，我們依照以往的思路便是創(chuàng)建一大堆表，運(yùn)用三范式或是依靠程序去保證數(shù)據(jù)的一致性不運(yùn)用主外鍵。然后瘋狂擼碼，CRUD 好不快活。
而隨著業(yè)務(wù)的逐漸擴(kuò)張，這當(dāng)初的想法已有點(diǎn)吃力了，如同樹苗逐漸成長，枝葉也逐漸增多。借助枝干我們可以分清葉子的歸屬，而對象網(wǎng)中呢，變得錯綜復(fù)雜了，也就隱約有了大泥球的征兆。
借助劃分聚合的一些方法，將其規(guī)整化。將原有復(fù)雜的對象圖拆分成可控制的小型對象圖。
保持單一導(dǎo)航方向，解除雙向依賴，保持依賴簡單。
保持聚合設(shè)計的小巧
聚合內(nèi)的業(yè)務(wù)規(guī)則一致性
通過聚合標(biāo)識符引用其他聚合
聚合與協(xié)作聚合間因業(yè)務(wù)場景、進(jìn)程邊界等因素影響，可依照場景使用強(qiáng)一致性或是最終一致性。
如上的對象圖依照關(guān)系的強(qiáng)弱，關(guān)系的主與次進(jìn)行了聚合劃分，或許得出的部分聚合存在不合理處，可再調(diào)整其邊界。
聚合協(xié)作
聚合與協(xié)作聚合之間依照聚合根實(shí)體的唯一標(biāo)識符進(jìn)行關(guān)聯(lián)，而不是通過依靠協(xié)作聚合的引用實(shí)例來完成。保持這個原則有助于保持聚合之間的邊界并避免加載不必要的對象。如我們常習(xí)慣上將關(guān)聯(lián)的集合對象寫入到類中，然后在倉儲使用時，通過 EF 加載導(dǎo)航屬性，以此方便直接加載關(guān)聯(lián)聚合數(shù)據(jù)。
//一個聚合內(nèi)建議用
public class Order : AggregateRoot
{
public virtual ICollection
OrdrItems { get;
set; }
//...
}
_orderRepository.Include(e=>e.OrderItems).FirstOrDefault();
如 Order 和 OrderItem，當(dāng)我們考慮將其作為一個聚合時，這么使用，是可以的，但是不能說跨聚合也這么用著，如 Enterprise 和 Order，劃分時我們更加傾向于劃分為兩個聚合，遵循保持聚合原則中，引用聚合根的 Id 這一原則，這將改善聚合的邊界使其更加清晰，控制更加妥當(dāng)。
//多聚合間不建議這么用
public class Order : AggregateRoot
{
//遵循聚合原則引用 Enterprice 聚合根 Id,而不是實(shí)例
public int EnterpriceId {get; set;}
//public virtual Enterprice Enterprice { get; set; }
//...
}
考慮到多聚合的協(xié)作，便要了解下聚合的首要原則，即在一次事務(wù)中，只能更改一個聚合的狀態(tài)，因此當(dāng)涉及到多個聚合協(xié)作時，如創(chuàng)建訂單完畢，需要往庫存中某一商品數(shù)量減少時，訂單本身一般會有商品聚合的標(biāo)識，借助這個標(biāo)識，通過領(lǐng)域事件或是集成事件方式，事件接收方將相關(guān)聯(lián)的庫存聚合調(diào)用起來，以此達(dá)到多個聚合間的協(xié)作。
又或者考慮到，需要調(diào)用商品的信息以使得當(dāng)前訂單中商品信息更加豐富，可通過防腐層調(diào)用商品所在上下文遠(yuǎn)程服務(wù)或是應(yīng)用服務(wù)，最終本質(zhì)上是調(diào)用商品聚合中的信息豐富到訂單中，也使得多個聚合完成協(xié)作。
應(yīng)用服務(wù)
作為限界上下文對外的門戶，也即是外觀模式的體現(xiàn)。通過用例分析識別出來的用例在此處一一對應(yīng)存在著，對外提供統(tǒng)一接口，以此滿足完整用例場景所需的功能。在應(yīng)用服務(wù)內(nèi)部，通過編排領(lǐng)域模型對象來完成用例的功能，自身并不包含領(lǐng)域邏輯，但包含著應(yīng)用邏輯。
可借鑒整潔架構(gòu)的經(jīng)典圖例來看應(yīng)用層本身的職責(zé)所在，Use Case(用例層)-Application Business Rules，雖然是依靠著領(lǐng)域模型對象才完成的（具體是編排領(lǐng)域模型對象所具有的領(lǐng)域行為），卻也說明了應(yīng)用服務(wù)承擔(dān)著的是用例的職責(zé)。
需要注意的是，應(yīng)用服務(wù)的職責(zé)不僅限于編排領(lǐng)域模型對象，還需要控制著橫切關(guān)注點(diǎn)，如驗證、日志、事物等的管理。
[UnitOfWork]
[Authorize(PermissionNames.PartType_Create)]
public async Task CreatePartType(CreatePartTypeDto input)
{
await _validatingPartTypeManager.CheckUniqueName(input.Name, input.Category);
var partType= PartType.Create(input.Name, input.Description)
.SetCategory(input.Category)
.SetFactory(input.FactoryName);
await _partTypeRepository.InsertAsync(partType);
await _appNotifier.NewPartTypeAsync();
}
如上，事務(wù)、認(rèn)證、請求參數(shù)校驗(Dto 內(nèi))，協(xié)調(diào)領(lǐng)域模型對象和基礎(chǔ)設(shè)施服務(wù)，這是應(yīng)用服務(wù)的職責(zé)，當(dāng)然也不僅限于這些職責(zé)。
領(lǐng)域服務(wù)
當(dāng)我們考慮領(lǐng)域邏輯時，首先想到的應(yīng)該是實(shí)體與值對象中具有的領(lǐng)域邏輯，而有些場景下，實(shí)體與值對象無法承載這些領(lǐng)域行為，如對多個領(lǐng)域?qū)ο笞鳛檩斎耄M(jìn)行計算并產(chǎn)出一個值對象；又或是需要將操作成集合化的聚合，如在 Supplier 下需要將所有 Order 中的單價匯總，而本身 Supplier 和 Order 是為兩個聚合，若考慮借助 Order 去完成該業(yè)務(wù)操作，不太妥當(dāng)，在此場景下，可通過領(lǐng)域服務(wù)來承載著這些領(lǐng)域行為。
領(lǐng)域服務(wù)存在如下特征：
執(zhí)行一個顯著的業(yè)務(wù)操作過程
對領(lǐng)域?qū)ο筮M(jìn)行轉(zhuǎn)換
需要使用多個聚合內(nèi)的實(shí)體和值對象編排業(yè)務(wù)邏輯
領(lǐng)域行為需要訪問外部資源
雖說領(lǐng)域服務(wù)能夠承載領(lǐng)域邏輯，卻不能說將所有的領(lǐng)域邏輯都往里塞，如此，導(dǎo)致領(lǐng)域?qū)ο筘氀?。只有?dāng)實(shí)體與值對象承載不住或是本身并不屬于實(shí)體或值對象的職責(zé)內(nèi)時，才考慮領(lǐng)域服務(wù)來承載，領(lǐng)域服務(wù)是一種妥協(xié)的結(jié)果，并不是說領(lǐng)域服務(wù)越多越好。
值對象（Value Object）→ 實(shí)體（Entity）→ 領(lǐng)域服務(wù)（Domain Service）
如下場景，創(chuàng)建 Invoice，存在幾條業(yè)務(wù)規(guī)則，相應(yīng) Order 的狀態(tài)需已完成，并且對應(yīng)的 Supplier 提供財月信息，這就需要多個聚合的協(xié)作，在領(lǐng)域服務(wù)編排這些領(lǐng)域?qū)ο竽Ｐ图巴ㄟ^調(diào)用外部服務(wù)網(wǎng)關(guān)，完成業(yè)務(wù)邏輯。
// InvoiceManager
public async Task ValidCheck(string orderId, string supplierId)
{
var order = await _orderService.GetAsync(orderId);
if(!order.IsCompleted())
{
throw new UserFriendlyException("Order status is not completed");
}
var supplier = await _supplierService.GetAsync(supplierId);
if(!supplier.IsCompleted())
{
throw new UserFriendlyException("Order status is not completed");
}
}
public async Task SetFinanceMonth(Invoice invoice, string supplierId)
{
var supplierFinanceMonth = await _supplierService.GetFinanceMonthAsync(supplierId, Current.Date);
if(supplierFinanceMonth == null)
{
throw new UserFriendlyException("Supplier not provider finance month");
}
invoice.SetFinanceMonth(supplierFinanceMonth.StartDate, supplierFinanceMonth.EndDate);
}
在應(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)域模型對象，完成一個業(yè)務(wù)用例。
領(lǐng)域事件
在軟件開發(fā)中，事件早已被我們所熟悉，一個按鈕按下，產(chǎn)生中斷事件，一個回車，前端頁面有偵聽事件，在事件風(fēng)暴建?；顒又?，事件也是作為領(lǐng)域建模的突破口，事件的重要性不言而喻。其本質(zhì)是發(fā)生的事實(shí)到引發(fā)了相關(guān)事情，在這其中的傳遞的信息便是事件的內(nèi)容。就如同貓叫了，引發(fā)著老鼠跑了，主人醒了，其中的事件便是貓叫了，而該事件是貓執(zhí)行叫的動作后的結(jié)果。
在領(lǐng)域驅(qū)動設(shè)計中，最開始的版本中并沒有領(lǐng)域事件的概念，在 DDD 社區(qū)對領(lǐng)域驅(qū)動設(shè)計的內(nèi)容不斷的充實(shí)中，引入了領(lǐng)域事件。領(lǐng)域事件的命名遵循英語中的“名詞 + 動詞過去分詞”格式，如，提交訂單后發(fā)布的 OrderCreated 事件，訂單完成后 OrderCompleted 事件，用以表示我們建模的領(lǐng)域中發(fā)生過的一件事情，也符合著事件本身是具有時間特征。
對于領(lǐng)域事件本身，依據(jù)各層的使用方式及面對的目標(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)前上下文或是其他上下文。
基于限界上下文間采用的部署方式不同，也存在著不同的通信方式，如整個應(yīng)用程序為單體，則所有上下文在同一個進(jìn)程內(nèi)，則上下文間事件交互時所采用的可以是進(jìn)程內(nèi)的事件總線，或是進(jìn)程間使用的消息隊列，而當(dāng)在進(jìn)程間時，就不得不使用進(jìn)程間的消息隊列了。
由于 DDD 中遵循一個用例對應(yīng)一個事務(wù)，在一個事務(wù)中更新一個聚合，因此對于實(shí)際場景中需要變更多個聚合下，我們常通過編排方式調(diào)用其他聚合的服務(wù)，這不可避免的加重了對其他服務(wù)的依賴，借助領(lǐng)域事件，則可以很方便的降低這種耦合，同時對于多個聚合的變更操作，由單個聚合的事務(wù)變成了多個聚合的事務(wù)，又依照實(shí)際影響的聚合情況，有著不同的處理方式，如多個協(xié)作的聚合為同一上下文內(nèi)時，可通過強(qiáng)一致性去保證數(shù)據(jù)一致性，而處于多個限界上下文間的聚合時，則可依照最終一致性保證數(shù)據(jù)的一致性。
領(lǐng)域事件主要用途有：
從事件角度豐富了領(lǐng)域模型
保證聚合間的數(shù)據(jù)一致性
實(shí)現(xiàn)事件事件溯源和 CQRS 等
限界上下文間集成(發(fā)布訂閱模式)
資源庫
在剛接觸資源庫(Repository)時，第一反應(yīng)便是這就是個 DAO 層，訪問數(shù)據(jù)庫，然后吧啦吧啦，但是，當(dāng)接觸的越久，越發(fā)認(rèn)識到第一反應(yīng)是錯的，資源庫更多的是對資源的管理，而不僅僅是數(shù)據(jù)庫中的數(shù)據(jù)，數(shù)據(jù)庫可以作為資源的一部分，但不是全部，我們習(xí)慣將對外部系統(tǒng)的調(diào)用稱為外部資源的獲取，這也是將外部系統(tǒng)作為資源的一部分。
對于聚合來講，資源庫的作用是負(fù)責(zé)將聚合持久化到數(shù)據(jù)庫的(通常是持久化到數(shù)據(jù)庫)，并且由于聚合根負(fù)責(zé)維持聚合的生命周期，也就使得應(yīng)考慮僅聚合根才應(yīng)該擁有資源庫，這也是與 DAO 層不同的地方。
在分層設(shè)計時，考慮將資源庫的抽象劃分到領(lǐng)域?qū)?，屬于領(lǐng)域模型對象的一部分，如同設(shè)計防腐層的抽象網(wǎng)關(guān)般，資源庫的抽象作為特殊的網(wǎng)關(guān)，當(dāng)在應(yīng)用層或是領(lǐng)域?qū)又胁僮髻Y源庫抽象時，將資源庫作為管理聚合狀態(tài)的工具，可以忽視基礎(chǔ)設(shè)施層中對資源庫的具體實(shí)現(xiàn)。而在考慮基礎(chǔ)設(shè)施層中具體實(shí)現(xiàn)時，可根據(jù)需要選擇適合的工具，以此來管理和操作資源。
工廠
聚合從 0 到 1 的過程，可以通過多種途徑創(chuàng)建，一般來講，我們開發(fā)中常直接實(shí)例化或是反射實(shí)例化，而對于聚合來講，整個聚合是一個整體，命運(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)掌握知識的多少與創(chuàng)建邏輯的需要可靈活選擇。
//...
var partType= PartType.Create(input.Name, input.Description)
.SetCategory(input.Category)
.SetFactory(input.FactoryName);
如借助構(gòu)建者模式，通過拆分許多小的方法，將過多的參數(shù)拆分，以此避免一個創(chuàng)建方法參數(shù)中滿屏都是參數(shù)的情況，需要考慮吧拆分的方法需要滿足業(yè)務(wù)一致性，如內(nèi)部的一些屬性間有約束條件下，需要劃分到一個方法中，以維持一致性或不變性。
學(xué)無止境
從2004年領(lǐng)域驅(qū)動設(shè)計到現(xiàn)在已經(jīng)有17年時間了，并且在其中還有諸如六邊形架構(gòu)，洋蔥架構(gòu)，整潔架構(gòu)等的出現(xiàn)，考慮的側(cè)重點(diǎn)不同，衍生著大量的新概念，也不斷地完善著領(lǐng)域驅(qū)動設(shè)計的思想。在學(xué)習(xí)與理解領(lǐng)域驅(qū)動設(shè)計中，總會有新的東西改變我們以往的思想，見到的越多，越發(fā)覺認(rèn)識的越少，這或許也是學(xué)起來有點(diǎn)阻力的原因吧。
參考
《實(shí)現(xiàn)領(lǐng)域驅(qū)動設(shè)計》- Vaughn Verno
《領(lǐng)域驅(qū)動設(shè)計實(shí)踐》- 張逸
《軟件架構(gòu)編年史》- herbertograca
領(lǐng)域驅(qū)動設(shè)計實(shí)現(xiàn)之路 - 滕云
領(lǐng)域驅(qū)動設(shè)計編碼實(shí)踐 - 滕云
Package by component and architecturally-aligned testing - Simon
2021-01-18,望技術(shù)有成后能回來看見自己的腳步
微信8.0大更新，附最新內(nèi)測版下載地址！
【古馳×張若昀×平安人壽】這3款紅包封面強(qiáng)勢來襲，趕快領(lǐng)取，手慢者無！