什么是DDD？
DDD全稱為(Domain-Driven Design,簡(jiǎn)稱DDD)，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
為什么要學(xué)習(xí)DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)？
在早期軟件開發(fā)，對(duì)于一些簡(jiǎn)單業(yè)務(wù)，只需要使用一個(gè)模塊，編寫多個(gè)業(yè)務(wù)邏輯就可以搞定。但是隨著
業(yè)務(wù)增長(zhǎng)，當(dāng)需要修改其中某一項(xiàng)功能，則修改困難，原因是 該功能可能會(huì)侵蝕其他代碼模塊。修改需要謹(jǐn)慎，投入時(shí)間成本，人力成本過高。DDD模型可以很好的解決這個(gè)問題。
DDD模型解決了什么問題?
粒度更小，架構(gòu)更加清晰，業(yè)務(wù)需求變化的時(shí)候，系統(tǒng)架構(gòu)也能隨之變化。DDD所呈現(xiàn)的系統(tǒng)必然是高內(nèi)聚，低耦合的，在業(yè)務(wù)系統(tǒng)中，不會(huì)因?yàn)樾薷腁模塊影響到了B模塊的使用。
1.過度耦合
在系統(tǒng)創(chuàng)建初期，業(yè)務(wù)初期，功能對(duì)于基礎(chǔ)設(shè)計(jì)都非常簡(jiǎn)單，普通的CRUD就可以滿足業(yè)務(wù)需要，但是隨著系統(tǒng)的迭代，業(yè)務(wù)邏輯變得復(fù)雜，此時(shí)系統(tǒng)的冗余程度也會(huì)隨之增加。此時(shí)需要修改其中某個(gè)節(jié)點(diǎn)的邏輯，可能伴隨著影響到其他模塊的業(yè)務(wù)邏輯。此問題的根源出現(xiàn)于 系統(tǒng)架構(gòu)不清晰，劃分出來的模塊內(nèi)聚度低，高耦合。
有一種解決方案，按照演進(jìn)式設(shè)計(jì)的理論，讓系統(tǒng)的設(shè)計(jì)隨著系統(tǒng)的實(shí)現(xiàn)的增長(zhǎng)而增長(zhǎng)。不需要提前設(shè)計(jì)，就讓系統(tǒng)伴隨業(yè)務(wù)成長(zhǎng)而演進(jìn)。
敏捷實(shí)踐中的重構(gòu)、測(cè)試驅(qū)動(dòng)設(shè)計(jì)及持續(xù)集成可以對(duì)付各種混亂問題。重構(gòu)--保持行為不變的代碼改善清除了額不協(xié)調(diào)的局部設(shè)計(jì)，測(cè)試驅(qū)動(dòng)設(shè)計(jì)確保對(duì)系統(tǒng)的更改不會(huì)導(dǎo)致系統(tǒng)丟失或破壞現(xiàn)有功能，持續(xù)集成則為團(tuán)隊(duì)提供了同一代碼庫。事實(shí)上，在解決現(xiàn)實(shí)問題的時(shí)候，我們會(huì)將問題映射到腦海中的概念模型，
在模型中解決問題，再將解決方案轉(zhuǎn)換為實(shí)際的代碼。上述問題 在于我們解決了設(shè)計(jì)到代碼之間的重構(gòu)，但提煉出來的設(shè)計(jì)模型，并不具有實(shí)際的業(yè)務(wù)含義，這就導(dǎo)致在開發(fā)需求的時(shí)候，其他同學(xué)不能自然的將業(yè)務(wù)問題映射到該設(shè)計(jì)模型。并不具有實(shí)際的業(yè)務(wù)含義。用DDD則可以很好的解決領(lǐng)域驅(qū)動(dòng)模型到設(shè)計(jì)模型的同步、演化，最后再將反映了領(lǐng)域的設(shè)計(jì)模型轉(zhuǎn)為實(shí)際的代碼。
注: 模型是我們解決實(shí)際問題所抽象出來的概念模型，領(lǐng)域模型則表達(dá)與業(yè)務(wù)相關(guān)的事實(shí)；設(shè)計(jì)模型則描述了所要構(gòu)建的系統(tǒng)。
貧血癥和失憶癥
貧血領(lǐng)域?qū)ο? 貧血領(lǐng)域?qū)ο?Anemic Domain Object)是指僅用做數(shù)據(jù)載體，而沒有行為和動(dòng)作的領(lǐng)域?qū)ο?/p>
- 場(chǎng)景需求
獎(jiǎng)池里配置了很多獎(jiǎng)項(xiàng)，我們需要按運(yùn)營(yíng)預(yù)先配置的概率抽中一個(gè)獎(jiǎng)項(xiàng)。 實(shí)現(xiàn)非常簡(jiǎn)單，生成一個(gè)隨機(jī)數(shù)，匹配符合該隨機(jī)數(shù)生成概率的獎(jiǎng)項(xiàng)即可。
- 貧血模型實(shí)現(xiàn)方案
先設(shè)計(jì)獎(jiǎng)池和獎(jiǎng)項(xiàng)的庫 2張數(shù)據(jù)庫表
class AwardPool { int awardPoolId; List<Award> awards; public List<Award> getAwards() { return awards; } public void setAwards(List<Award> awards) { this.awards = awards; } ...... } class Award { int awardId; int probability;//概率 ...... } Service的實(shí)現(xiàn) AwardPool awardPool = awardPoolDao.getAwardPool(poolId);//sql查詢，將數(shù)據(jù)映射到AwardPool對(duì)象 for (Award award : awardPool.getAwards()) { //尋找到符合award.getProbability()概率的award }
按照傳統(tǒng)開發(fā)思想，可以發(fā)現(xiàn):我們的業(yè)務(wù)邏輯都是再Service中去編寫的，Award只是一個(gè)數(shù)據(jù)載體，沒有任何行為。簡(jiǎn)單的業(yè)務(wù)系統(tǒng)采用這種貧血模型和過程化設(shè)計(jì)是沒有問題的 但是業(yè)務(wù)邏輯一旦復(fù)雜了，業(yè)務(wù)邏輯，狀態(tài)會(huì)散落在大量的方法中，原本的代碼意圖會(huì)漸漸不明確，我們將這種情況稱為由貧血引起的失憶癥
更好的是采用領(lǐng)域模型的開發(fā)方式，將數(shù)據(jù)和行為封裝在一起，并與現(xiàn)實(shí)世界中的業(yè)務(wù)對(duì)象映射各類具備明確的職責(zé)劃分，將領(lǐng)域邏輯分散到領(lǐng)域?qū)ο笾?。按照這種思想，上述的例子 就應(yīng)該把概率放在AwardPool當(dāng)中
軟件系統(tǒng)復(fù)雜性應(yīng)對(duì)
解決
復(fù)雜和大規(guī)模軟件的武器可以被粗略地歸為三類:抽象、分治和知識(shí)1.分治:把問題空間分割為規(guī)模更下且易于處理的若干子問題。分割后的問題需要足夠小，以便一個(gè)人單槍匹馬也可以解決。其次，必須考慮如何將分割后的各個(gè)部分裝配為整體。分割的越合理越易于理解，在裝配整體時(shí)候，需要跟蹤的細(xì)節(jié)也就越小。即更容易設(shè)計(jì)各部分的協(xié)作方式。評(píng)判什么是分治的好，即高內(nèi)聚，低耦合。
2.抽象: 使用抽象能夠精簡(jiǎn)問題空間，而且問題越小越容易理解，舉個(gè)例子，從北京到上海出差，可以先理解為使用交通工具，但不需要一開始就確定是采用飛機(jī)，自駕，高鐵的形式。
3.知識(shí): DDD可以認(rèn)為是知識(shí)的一種。
DDD提供了這樣的知識(shí)手段，讓我們知道如何抽象出上下限的界限以及如何去分治。
與微服務(wù)架構(gòu)相得益彰
在創(chuàng)建微服務(wù)的時(shí)候，需要?jiǎng)?chuàng)建一個(gè)高內(nèi)聚，低耦合的微服務(wù)。而DDD中的限界上下文則完美匹配微服務(wù)要求，可以將該限界上下文理解為一個(gè)微服務(wù)進(jìn)程。
在系統(tǒng)復(fù)雜之后，都需要分治來拆解問題，一般有兩種方式
技術(shù)維度和業(yè)務(wù)維度，技術(shù)維度是類似mvc的樣子，業(yè)務(wù)維度則是指按照業(yè)務(wù)領(lǐng)域來劃分系統(tǒng)。微服務(wù)架構(gòu)更強(qiáng)調(diào)從業(yè)務(wù)維度去做分治來應(yīng)對(duì)系統(tǒng)復(fù)雜度，而DDD也是同樣的著重業(yè)務(wù)視角，如果
兩者在追求目標(biāo)(業(yè)務(wù)維度)達(dá)到了統(tǒng)一在具體的做法下面可能有如下不同點(diǎn)。我們將架構(gòu)設(shè)計(jì)活動(dòng)精簡(jiǎn)為以下層面:
- 業(yè)務(wù)架構(gòu):根據(jù)業(yè)務(wù)需求設(shè)計(jì)業(yè)務(wù)模塊和關(guān)系
- 系統(tǒng)架構(gòu):設(shè)計(jì)系統(tǒng)和子系統(tǒng)的模塊
- 技術(shù)架構(gòu):決定采用的技術(shù)及框架
以上三種活動(dòng)在實(shí)際開發(fā)中是有先后順序的但不一定誰先誰后。在解決常規(guī)套路問題的時(shí)候，很自然地往熟悉的分層架構(gòu)套。在業(yè)務(wù)不復(fù)雜的時(shí)候這樣是合理的。
跳過業(yè)務(wù)架構(gòu)設(shè)計(jì)出來的架構(gòu)關(guān)注點(diǎn)不在業(yè)務(wù)響應(yīng)上，在面臨需求迭代響應(yīng)市場(chǎng)變化地時(shí)候就很痛苦
DDD地核心訴求就是將業(yè)務(wù)架構(gòu)映射到系統(tǒng)架構(gòu)上，在響應(yīng)業(yè)務(wù)變化調(diào)整架構(gòu)的時(shí)候，也隨之變化系統(tǒng)架構(gòu)。而微服務(wù)追求業(yè)務(wù)層面的服用，設(shè)計(jì)出來的系統(tǒng)架構(gòu)和業(yè)務(wù)一致；在技術(shù)架構(gòu)上則系統(tǒng)模塊之間 充分解耦，可以自由選擇合適的技術(shù)架構(gòu)，去中心化地治理技術(shù)和數(shù)據(jù)。
[圖片上傳失敗...(image-a96260-1634801926133)]設(shè)計(jì)領(lǐng)域模型的一般步驟如下:
- 根據(jù)需求劃分出初步的領(lǐng)域和限界上下文，以及上下文之間的關(guān)系；
- 進(jìn)一步分析每個(gè)上下文內(nèi)部，識(shí)別出哪些是實(shí)體，哪些是值對(duì)象
- 對(duì)實(shí)體、值對(duì)象進(jìn)行關(guān)聯(lián)聚合，劃分出聚合的范疇和聚合根
- 為聚合根設(shè)計(jì)倉儲(chǔ)，并思考實(shí)體或值對(duì)象的創(chuàng)建方式
- 在工程中實(shí)踐領(lǐng)域模型，并且在實(shí)踐中檢驗(yàn)?zāi)Ｐ偷暮侠硇?，倒推模型中的不足的地方并重?gòu)
戰(zhàn)略建模
戰(zhàn)略和戰(zhàn)術(shù)設(shè)計(jì)是站在DDD的角度進(jìn)行劃分。戰(zhàn)略設(shè)計(jì)側(cè)重于高層次、宏觀上去劃分和集成限界上下文，而戰(zhàn)術(shù)設(shè)計(jì)則關(guān)注更具體使用建模工具來細(xì)化上下文。
領(lǐng)域
現(xiàn)實(shí)世界中，領(lǐng)域包含了問題域和解系統(tǒng)。一般認(rèn)為軟件是對(duì)現(xiàn)實(shí)世界的部分模擬，在DDD中，解系統(tǒng)可以映射為一個(gè)個(gè)限界上下文，限界上下文就是軟件對(duì)于問題域的一個(gè)特定的、有限的解決方案。
限界上下文
一個(gè)由邊界限定的特定職責(zé)。領(lǐng)域模型便在于這個(gè)邊界之類。在邊界內(nèi)，每一個(gè)模型概念，包括它的屬性和操作都具有特殊的含義
一個(gè)給定的業(yè)務(wù)領(lǐng)域會(huì)包含多個(gè)上下文，想與一個(gè)限界上下文溝通，則需要通過現(xiàn)實(shí)邊界進(jìn)行通信。系統(tǒng)通過確定的限界上下文來進(jìn)行解耦，而每一個(gè)上下文內(nèi)部緊密組織，職責(zé)明確，具有較高的內(nèi)聚性。
一個(gè)很形象的比喻:細(xì)胞之所以能夠存在，是因?yàn)榧?xì)胞膜限定了在什么細(xì)胞內(nèi)，什么在細(xì)胞外，并且確定了什么物質(zhì)可以通過細(xì)胞膜。
劃分限界上下文
劃分限界上下文，不應(yīng)該采用技術(shù)架構(gòu)或者開發(fā)任務(wù)來創(chuàng)建限界上下文,
應(yīng)該按照語義的邊界來考慮。我們的實(shí)踐，考慮產(chǎn)品所講的通用語言，從中提取一些術(shù)語稱之為概念對(duì)象，尋找對(duì)象之間的聯(lián)系；或者從需求里提取一些動(dòng)詞，觀察動(dòng)詞和對(duì)象之間的關(guān)系；我們將緊耦合的各自圈在一起，觀察他們內(nèi)在的聯(lián)系，從而形成對(duì)應(yīng)的界限上下文。形成之后，我們可以嘗試用語言來面熟下界上下文的職責(zé)，看它是否清晰、準(zhǔn)確、簡(jiǎn)潔和完整。簡(jiǎn)言之，限界上下文應(yīng)該從需求出發(fā)，按領(lǐng)域劃分前文提到的，用戶劃分分為運(yùn)營(yíng)和用戶。其中，運(yùn)營(yíng)對(duì)抽獎(jiǎng)的活動(dòng)的配置十分復(fù)雜，但相對(duì)低頻。用戶對(duì)這些抽獎(jiǎng)的活動(dòng)配置使用的是高頻次且無感知的。根據(jù)這些業(yè)務(wù)特點(diǎn)，首先將抽獎(jiǎng)平臺(tái)劃分為C端和M端抽獎(jiǎng)管理平臺(tái)2個(gè)子域，讓兩者完全解耦
[圖片上傳失敗...(image-57c2cd-1633749292025)]
在確認(rèn)了M端領(lǐng)域和C端的限界上下文后，我們?cè)趯?duì)各自的上下文內(nèi)部進(jìn)行限界上下文的劃分。采用C端舉例
產(chǎn)品的需求概述如下:
- 抽獎(jiǎng)活動(dòng)有活動(dòng)限制，例如用戶的抽獎(jiǎng)次數(shù)限制，抽獎(jiǎng)的開始和結(jié)束的時(shí)間等；
- 一個(gè)抽獎(jiǎng)活動(dòng)包含多個(gè)獎(jiǎng)品，可以針對(duì)一個(gè)或多個(gè)用戶群體
- 獎(jiǎng)品有自身的獎(jiǎng)品配置，例如庫存量，被抽中的概率等，最多被一個(gè)用戶抽中的次數(shù)等等；
- 用戶群體有多種區(qū)別方式，如按照用戶所在城市區(qū)分，按照新老客區(qū)分等；
- 活動(dòng)具有風(fēng)控配置，能夠限制用戶參與抽獎(jiǎng)的頻率。
根據(jù)產(chǎn)品的需求提取出一些關(guān)鍵性的概念作為子域，形成限界上下文
[圖片上傳失敗...(image-d3758f-1633749292025)]
首先把抽獎(jiǎng)作為整個(gè)子域 的核心，承擔(dān)著用戶抽獎(jiǎng)的核心業(yè)務(wù)，抽獎(jiǎng)中包含了獎(jiǎng)品和用戶群體的概念。曾考慮分出抽獎(jiǎng)和發(fā)獎(jiǎng)2個(gè)領(lǐng)域，前者復(fù)雜抽獎(jiǎng) 后者負(fù)責(zé)將獎(jiǎng)品發(fā)送出去。但在實(shí)際開發(fā)過程中，我們發(fā)現(xiàn)這兩部分的邏輯緊密連接，難以拆分。
對(duì)于活動(dòng)的限制，定義了活動(dòng)準(zhǔn)入的通用語言，將活動(dòng)開始/結(jié)束實(shí)踐，活動(dòng)可參與次數(shù)等限制條件都收攏到活動(dòng)準(zhǔn)入上下文中。
對(duì)于抽獎(jiǎng)的庫存量，由于庫存的行為與獎(jiǎng)品本身相對(duì)解耦，庫存關(guān)注點(diǎn)更多是庫存內(nèi)的數(shù)量核銷，且?guī)齑姹旧砭哂型ㄓ眯?，可以唄獎(jiǎng)品之外的內(nèi)容使用，因此可以定義一個(gè)庫存上下文。
由于C端存在一些刷單行為，根據(jù)產(chǎn)品需求定義風(fēng)控上下文，對(duì)于活動(dòng)進(jìn)行風(fēng)控。最后，活動(dòng)準(zhǔn)入，風(fēng)控抽獎(jiǎng)等領(lǐng)域設(shè)計(jì)到了計(jì)數(shù)的限制，因此定義了計(jì)數(shù)上下文。
可以看到通過，DDD模型的限界上下文的劃分，界定出抽獎(jiǎng)、活動(dòng)準(zhǔn)入、風(fēng)控、計(jì)數(shù)、庫存等五個(gè)上下文每個(gè)上下文在系統(tǒng)都高度內(nèi)聚。
上下文映射圖
在進(jìn)行上下文劃分之后，我們還需要進(jìn)一步梳理上下文之間的關(guān)系。
康威定律: 任何組織在設(shè)計(jì)一套系統(tǒng)時(shí)，所交付的設(shè)計(jì)方案在機(jī)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致。
康威定律告訴我們，
系統(tǒng)結(jié)構(gòu)應(yīng)盡量的與組織機(jī)構(gòu)保持一致這里我們認(rèn)為團(tuán)隊(duì)結(jié)構(gòu)就是組織結(jié)構(gòu)，限界上下文就是系統(tǒng)的業(yè)務(wù)結(jié)構(gòu)。因此，團(tuán)隊(duì)結(jié)構(gòu)應(yīng)該和限界上下文保持一致。梳理清楚上下文之間的關(guān)系，從團(tuán)隊(duì)內(nèi)部的關(guān)系來看。
- 任務(wù)更好拆分，一個(gè)開發(fā)人員可以全身心的投入到相關(guān)的一個(gè)單獨(dú)的上下文中
- 溝通更加順暢，一個(gè)上下文可以明確自己對(duì)其他上下文的依賴關(guān)系，從而使得團(tuán)隊(duì)內(nèi)開發(fā)直接更好的對(duì)接，從團(tuán)隊(duì)關(guān)系來看，明確的上下文關(guān)系能夠帶來如下幫助
1. 每個(gè)團(tuán)隊(duì)在它的上下文中能夠明確自己領(lǐng)域內(nèi)的概念，因?yàn)樯舷挛氖穷I(lǐng)域的解系統(tǒng)。 2. 對(duì)于限界上下文之間發(fā)生交互，團(tuán)隊(duì)與上下文的一致性，能夠保證我們明確對(duì)接的團(tuán)隊(duì)和依賴的上下游。限界上下文之間的依賴關(guān)系
- 合作關(guān)系:兩個(gè)上下文緊密合作的關(guān)系，一榮俱榮，一損俱損
- 共享內(nèi)核: 兩個(gè)上下文依賴部分共享的模型
- 客戶方—>供應(yīng)方開發(fā):上下文之間有組織的上下游依賴。
- 遵奉者 :下游上下文只能盲目依賴上游上下文
- 防腐層: 一個(gè)上下文通過一些適配和轉(zhuǎn)換與另一個(gè)上下文交互。
- 開放主機(jī)服務(wù):定義一種協(xié)議來讓其他上下文來對(duì)本上下文進(jìn)行訪問
- 發(fā)布語言:通常OHS一起使用，用于定義開放主機(jī)的協(xié)議
- 大泥球: 混雜再一起的上下文關(guān)系，邊界不清晰
- 另謀他路: 兩個(gè)完全沒有任何聯(lián)系的上下文。
上文定義了上下文映射間的關(guān)系，經(jīng)過反復(fù)斟酌，抽獎(jiǎng)平臺(tái)上下文的映射關(guān)系圖如下:
[圖片上傳失敗...(image-19ac1a-1634801926133)]
由于抽獎(jiǎng)，風(fēng)控，活動(dòng)準(zhǔn)入，庫存，計(jì)數(shù)上下文都處再抽獎(jiǎng)?lì)I(lǐng)域的內(nèi)部，所以它們之間符合"一榮俱榮，一損俱損"的合作關(guān)系 PS。
同時(shí)，抽獎(jiǎng)上下文再進(jìn)行發(fā)卷的時(shí)候會(huì)依賴于，卷碼，等上下文，抽獎(jiǎng)上下文通過防腐層作為發(fā)布語言對(duì)抽獎(jiǎng)上下文提供訪問機(jī)制
通過上下文映射關(guān)系，明確限制了上下文的耦合性，在抽獎(jiǎng)平臺(tái)中，無論是上下文內(nèi)部交互還是與外部上下文交互，耦合度都限定在數(shù)據(jù)耦合的層級(jí)
戰(zhàn)術(shù)建模-細(xì)化上下文
梳理清楚上下文之間的關(guān)系后，我們需要從戰(zhàn)術(shù)層面上剖析上下文內(nèi)部的組織關(guān)系。
實(shí)體:
當(dāng)一個(gè)對(duì)象由其表示區(qū)分時(shí)，這種對(duì)象稱為實(shí)體。
最簡(jiǎn)單的，公安系統(tǒng)的身份信息錄入，對(duì)于人的模擬，即認(rèn)為是實(shí)體，因?yàn)槊總€(gè)人是獨(dú)一無二的，且其具有唯一標(biāo)識(shí)。
在時(shí)間上建議將熟悉的驗(yàn)證放到試題中
值對(duì)象:
當(dāng)一個(gè)對(duì)象用于對(duì)事物進(jìn)行描述而沒有唯一標(biāo)識(shí)時(shí)，它被稱為值對(duì)象，
比如顏色信息:我們只需要知道{"name":"黑色"，"css":"#000000"}這樣的值信息就能夠滿足要求了，這避免了我們對(duì)標(biāo)識(shí)追蹤帶來的系統(tǒng)復(fù)雜性。
值對(duì)象很重要，在習(xí)慣了使用數(shù)據(jù)庫的數(shù)據(jù)建模后，很容易將所有對(duì)象看作實(shí)體。使用值對(duì)象可以更好地系統(tǒng)優(yōu)化，精簡(jiǎn)設(shè)計(jì)
它具有不變性、相等性和可替換性
在實(shí)踐中，需要保證值對(duì)象創(chuàng)建后就不能被修改，即不允許外部再修改其屬性。在不同上下文集成時(shí)，會(huì)出現(xiàn)模型概念的公用，如商品模型會(huì)存在于電商的各個(gè)上下文中，在訂單上下文中如果你只關(guān)注下單時(shí)地商品信息快照，那么將商品對(duì)象視為值對(duì)象是很好的選擇。
聚合根:
Aggregate是一組相關(guān)對(duì)象地集合，作為一個(gè)整體被外界訪問，聚合根是這個(gè)聚合地根節(jié)點(diǎn)。
聚合是一個(gè)非常重要的概念，核心領(lǐng)域往往都需要聚合來表達(dá)。其次，聚合在技術(shù)上有非常高的價(jià)值，可以指導(dǎo)詳細(xì)設(shè)計(jì)。
聚合由根實(shí)體，值對(duì)象和實(shí)體組成。
如何創(chuàng)建好的聚合?
邊界內(nèi)的內(nèi)容具有一致性·:在一個(gè)事務(wù)只修改一個(gè)聚合實(shí)例，如果你發(fā)現(xiàn)邊界內(nèi)很難接受強(qiáng)一致，不管是出于性能或產(chǎn)品需求的考慮，應(yīng)該考慮剝離出獨(dú)立的聚合，采用最終一致的方式。
設(shè)計(jì)小聚合: 大部分的聚合都可以只包含根實(shí)體，而無需包含其他實(shí)體。即使一定要包含，可以考慮將其創(chuàng)建為值對(duì)象。
通過唯一標(biāo)識(shí)來引用其他聚合或?qū)嶓w:當(dāng)存在對(duì)象之間的關(guān)聯(lián)時(shí)，建議引用其唯一標(biāo)識(shí)而非引用其整體對(duì)象。如果是外部上下文中的實(shí)體，引用其唯一標(biāo)識(shí)或?qū)⑿枰氖煜?gòu)造值對(duì)象，如果聚合創(chuàng)建復(fù)雜，推薦使用工廠方法來屏蔽內(nèi)部復(fù)雜的創(chuàng)建邏輯。聚合內(nèi)部多個(gè)組成對(duì)象的關(guān)系可以用來指導(dǎo)數(shù)據(jù)庫創(chuàng)建，但不可避免存在一定的抗阻。如聚合中存在List<值對(duì)象>那么在數(shù)據(jù)庫中建立 1:N的關(guān)聯(lián)需要將值對(duì)象單獨(dú)建表，此時(shí)是有id的 建議不要將改id暴露到資源庫外部，對(duì)外隱蔽
領(lǐng)域服務(wù):一些重要的領(lǐng)域行為或操作，可以歸類為領(lǐng)域服務(wù)，它既不是實(shí)體，也不是值對(duì)象的范疇。
當(dāng)我們采用了微服務(wù)架構(gòu)風(fēng)格，一切領(lǐng)域邏輯的對(duì)外暴露均需要通過領(lǐng)域服務(wù)來進(jìn)行。如原本由聚合根暴露的業(yè)務(wù)邏輯也需要依托于領(lǐng)域服務(wù)
領(lǐng)域事件:領(lǐng)域事件是對(duì)領(lǐng)域內(nèi)發(fā)生的活動(dòng)進(jìn)行的建模。
抽獎(jiǎng)平臺(tái)的核心上下文是抽獎(jiǎng)。接下來介紹一下對(duì)抽獎(jiǎng)上下文的建模。
[圖片上傳失敗...(image-e79b38-1634801926133)]
抽獎(jiǎng)上下文中，通過DrawLottery 這個(gè)聚合根來控制抽獎(jiǎng)的行文。可以看到一個(gè)抽獎(jiǎng)包括了抽獎(jiǎng)ID(LotteryId）以及多個(gè)獎(jiǎng)池（AwardPool），而一個(gè)獎(jiǎng)池針對(duì)一個(gè)特定的用戶群體（UserGroup）設(shè)置了多個(gè)獎(jiǎng)品（Award）。
另外，在抽獎(jiǎng)?lì)I(lǐng)域中，我們還會(huì)使用抽獎(jiǎng)結(jié)果(SendResult)作為輸出信息，使用用戶領(lǐng)獎(jiǎng)記錄(UserLotteryLog)作為領(lǐng)獎(jiǎng)憑據(jù)和存根。
謹(jǐn)慎使用值對(duì)象
在實(shí)踐中，我們發(fā)現(xiàn)雖然一些領(lǐng)域?qū)ο蠓现祵?duì)象的概念，但是隨著業(yè)務(wù)的變動(dòng)，很多原有的定義會(huì)發(fā)生變更，值對(duì)象可能需要在業(yè)務(wù)意義具有唯一標(biāo)識(shí)，而對(duì)這類值對(duì)象的重構(gòu)往往需要較高成本。因此在特定的情況下，我們也要根據(jù)實(shí)際情況來權(quán)衡領(lǐng)域?qū)ο蟮倪x型。
DDD工程實(shí)現(xiàn)
模塊
模塊(Module)是DDD中明確提到的一種控制限界上下文的手段，在我們的工程中，一般盡量用一個(gè)模塊來標(biāo)識(shí)一個(gè)領(lǐng)域的限界上下文
如代碼中所示，一般的工程包的組織方式為{com.公司名.組織架構(gòu).業(yè)務(wù).上下文.*}，這樣的組織結(jié)構(gòu)能夠明確將一個(gè)上下文限定在包的內(nèi)部
import com.company.team.bussiness.lottery.*;//抽獎(jiǎng)上下文 import com.company.team.bussiness.riskcontrol.*;//風(fēng)控上下文 import com.company.team.bussiness.counter.*;//計(jì)數(shù)上下文 import com.company.team.bussiness.condition.*;//活動(dòng)準(zhǔn)入上下文 import com.company.team.bussiness.stock.*;//庫存上下文對(duì)于模塊內(nèi)的組織機(jī)構(gòu)，一般情況下我們是按照領(lǐng)域?qū)ο蟆㈩I(lǐng)域服務(wù)、領(lǐng)域資源庫、防腐層等組織方式定義的
import com.company.team.bussiness.lottery.domain.valobj.*;//領(lǐng)域?qū)ο?值對(duì)象 import com.company.team.bussiness.lottery.domain.entity.*;//領(lǐng)域?qū)ο?實(shí)體 import com.company.team.bussiness.lottery.domain.aggregate.*;//領(lǐng)域?qū)ο?聚合根 import com.company.team.bussiness.lottery.service.*;//領(lǐng)域服務(wù) import com.company.team.bussiness.lottery.repo.*;//領(lǐng)域資源庫 import com.company.team.bussiness.lottery.facade.*;//領(lǐng)域防腐層領(lǐng)域?qū)ο?/h5>
領(lǐng)域驅(qū)動(dòng)要解決的一個(gè)重要問題就是解決貧血問題。這里采用之前定義的抽獎(jiǎng)聚合根和獎(jiǎng)池AwardPool值對(duì)象來具體說明
抽獎(jiǎng)聚合根持有了抽獎(jiǎng)的活動(dòng)的id，和所有可用的獎(jiǎng)池列表，它的一個(gè)最主要的領(lǐng)域功能就是根據(jù)一個(gè)抽獎(jiǎng)發(fā)生場(chǎng)景，選出一個(gè)適配的獎(jiǎng)池。chooseAwardPool方法
chooseAwardPool的邏輯是這樣的:DrawLotteryContext會(huì)帶有用戶抽獎(jiǎng)時(shí)的場(chǎng)景信息，DrawLottery會(huì)根據(jù)這個(gè)場(chǎng)景信息，匹配一個(gè)可以給用戶發(fā)獎(jiǎng)的AwardPool。
package com.company.team.bussiness.lottery.domain.aggregate; import ...; public class DrawLottery { private int lotteryId; //抽獎(jiǎng)id private List<AwardPool> awardPools; //獎(jiǎng)池列表 //getter & setter public void setLotteryId(int lotteryId) { if(id<=0){ throw new IllegalArgumentException("非法的抽獎(jiǎng)id"); } this.lotteryId = lotteryId; } //根據(jù)抽獎(jiǎng)入?yún)ontext選擇獎(jiǎng)池 public AwardPool chooseAwardPool(DrawLotteryContext context) { if(context.getMtCityInfo()!=null) { return chooseAwardPoolByCityInfo(awardPools, context.getMtCityInfo()); } else { return chooseAwardPoolByScore(awardPools, context.getGameScore()); } } //根據(jù)抽獎(jiǎng)所在城市選擇獎(jiǎng)池 private AwardPool chooseAwardPoolByCityInfo(List<AwardPool> awardPools, MtCifyInfo cityInfo) { for(AwardPool awardPool: awardPools) { if(awardPool.matchedCity(cityInfo.getCityId())) { return awardPool; } } return null; } //根據(jù)抽獎(jiǎng)活動(dòng)得分選擇獎(jiǎng)池 private AwardPool chooseAwardPoolByScore(List<AwardPool> awardPools, int gameScore) {...} }在匹配到一個(gè)具體的獎(jiǎng)池之后，需要確定給用戶的獎(jiǎng)品，這部分的領(lǐng)域功能放在AwardPool內(nèi)
package com.company.team.bussiness.lottery.domain.valobj; import ...; public class AwardPool { private String cityIds;//獎(jiǎng)池支持的城市 private String scores;//獎(jiǎng)池支持的得分 private int userGroupType;//獎(jiǎng)池匹配的用戶類型 private List<Awrad> awards;//獎(jiǎng)池中包含的獎(jiǎng)品 //當(dāng)前獎(jiǎng)池是否與城市匹配 public boolean matchedCity(int cityId) {...} //當(dāng)前獎(jiǎng)池是否與用戶得分匹配 public boolean matchedScore(int score) {...} //根據(jù)概率選擇獎(jiǎng)池 public Award randomGetAward() { int sumOfProbablity = 0; for(Award award: awards) { sumOfProbability += award.getAwardProbablity(); } int randomNumber = ThreadLocalRandom.current().nextInt(sumOfProbablity); range = 0; for(Award award: awards) { range += award.getProbablity(); if(randomNumber<range) { return award; } } return null; } }與以往的getter、setter業(yè)務(wù)對(duì)象不同，領(lǐng)域?qū)ο缶哂辛诵袨?，?duì)象更加豐滿，同時(shí)，比起將這些邏輯寫在service內(nèi)，領(lǐng)域功能的內(nèi)聚性更強(qiáng)，職責(zé)更加明確。
資源庫
領(lǐng)域?qū)ο笮枰Y源庫，存儲(chǔ)的手段可以是多樣化的，常見的無非是數(shù)據(jù)庫，分布式緩存，本地緩存等。資源庫的作用，是對(duì)領(lǐng)域的存儲(chǔ)和訪問進(jìn)行統(tǒng)一管理的對(duì)象。在抽獎(jiǎng)平臺(tái)上，是通過如下的方式組織資源庫的
//數(shù)據(jù)庫資源 import com.company.team.bussiness.lottery.repo.dao.AwardPoolDao;//數(shù)據(jù)庫訪問對(duì)象-獎(jiǎng)池 import com.company.team.bussiness.lottery.repo.dao.AwardDao;//數(shù)據(jù)庫訪問對(duì)象-獎(jiǎng)品 import com.company.team.bussiness.lottery.repo.dao.po.AwardPO;//數(shù)據(jù)庫持久化對(duì)象-獎(jiǎng)品 import com.company.team.bussiness.lottery.repo.dao.po.AwardPoolPO;//數(shù)據(jù)庫持久化對(duì)象-獎(jiǎng)池 import com.company.team.bussiness.lottery.repo.cache.DrawLotteryCacheAccessObj;//分布式緩存訪問對(duì)象-抽獎(jiǎng)緩存訪問 import com.company.team.bussiness.lottery.repo.repository.DrawLotteryRepository;//資源庫訪問對(duì)象-抽獎(jiǎng)資源庫資源庫對(duì)外的整體訪問由Respository提供，它聚合了各個(gè)資源庫的數(shù)據(jù)信息，同時(shí)也承擔(dān)了資源庫存儲(chǔ)的邏輯(例如緩存更新機(jī)制等)
在抽獎(jiǎng)資源庫中，我們屏蔽了對(duì)底層獎(jiǎng)池和獎(jiǎng)品的直接訪問，僅對(duì)抽獎(jiǎng)的聚合根進(jìn)行資源管理。代碼示例中展示了抽獎(jiǎng)資源獲取的方法(最常見的Cache Aside Pattern)
比起以往將資源管理放在服務(wù)的做法，由資源庫進(jìn)行管理，職責(zé)更加明確，代碼可讀性和可維護(hù)性更強(qiáng)。
package com.company.team.bussiness.lottery.repo; import ...; @Repository public class DrawLotteryRepository { @Autowired private AwardDao awardDao; @Autowired private AwardPoolDao awardPoolDao; @AutoWired private DrawLotteryCacheAccessObj drawLotteryCacheAccessObj; public DrawLottery getDrawLotteryById(int lotteryId) { DrawLottery drawLottery = drawLotteryCacheAccessObj.get(lotteryId); if(drawLottery!=null){ return drawLottery; } drawLottery = getDrawLotteyFromDB(lotteryId); drawLotteryCacheAccessObj.add(lotteryId, drawLottery); return drawLottery; } private DrawLottery getDrawLotteryFromDB(int lotteryId) {...} }防腐層
亦稱適配層，在一個(gè)上下文中，有時(shí)需要對(duì)外部上下文進(jìn)行訪問，通常會(huì)引入防腐層的概念來對(duì)外部上下文的訪問進(jìn)行一次轉(zhuǎn)移。
有以下幾種情況會(huì)考慮引入防腐層。
- 需要將外部上下文的模型翻譯成本上下文理解的模型
- 不同上下文之間的團(tuán)隊(duì)協(xié)作關(guān)系，如果是供奉者關(guān)系，建議引入防腐層，避免外部上下文變化對(duì)本上下文的侵蝕
- 該訪問本上下文使用廣泛，為了避免改動(dòng)影響范圍太大。
如果內(nèi)部多個(gè)上下文對(duì)外部上下文需要訪問，那么可以考慮將其放到通用上下文中
在抽獎(jiǎng)平臺(tái)中，定義了用戶城市信息防腐層,用于外部的用戶城市信息上下文。以用戶信息防腐層距離，它以抽獎(jiǎng)?wù)埱髤?shù)為參，以城市信息MtCityInfo為輸出
package com.company.team.bussiness.lottery.facade; import ...; @Component public class UserCityInfoFacade { @Autowired private LbsService lbsService;//外部用戶城市信息RPC服務(wù) public MtCityInfo getMtCityInfo(LotteryContext context) { LbsReq lbsReq = new LbsReq(); lbsReq.setLat(context.getLat()); lbsReq.setLng(context.getLng()); LbsResponse resp = lbsService.getLbsCityInfo(lbsReq); return buildMtCifyInfo(resp); } private MtCityInfo buildMtCityInfo(LbsResponse resp) {...} }領(lǐng)域服務(wù)
上文中，我們將領(lǐng)域行為封裝到領(lǐng)域?qū)ο笾校瑢①Y源管理行為封裝到資源庫中，將外部上下文的交互行為封裝到防腐層中。此時(shí)，我們?cè)倩剡^頭來看領(lǐng)域服務(wù)時(shí)，能夠發(fā)現(xiàn)領(lǐng)域服務(wù)本身所承載的職責(zé)也就更加清晰了，即就是通過串聯(lián)領(lǐng)域?qū)ο蟆①Y源庫和防腐層等一系列領(lǐng)域內(nèi)的對(duì)象的行為，對(duì)其他上下文提供交互的接口。
我們以抽獎(jiǎng)服務(wù)為例（issueLottery），可以看到在省略了一些防御性邏輯（異常處理，空值判斷等）后，領(lǐng)域服務(wù)的邏輯已經(jīng)足夠清晰明了。
package com.company.team.bussiness.lottery.service.impl import ...; @Service public class LotteryServiceImpl implements LotteryService { @Autowired private DrawLotteryRepository drawLotteryRepo; @Autowired private UserCityInfoFacade UserCityInfoFacade; @Autowired private AwardSendService awardSendService; @Autowired private AwardCounterFacade awardCounterFacade; @Override public IssueResponse issueLottery(LotteryContext lotteryContext) { DrawLottery drawLottery = drawLotteryRepo.getDrawLotteryById(lotteryContext.getLotteryId());//獲取抽獎(jiǎng)配置聚合根 awardCounterFacade.incrTryCount(lotteryContext);//增加抽獎(jiǎng)計(jì)數(shù)信息 AwardPool awardPool = lotteryConfig.chooseAwardPool(bulidDrawLotteryContext(drawLottery, lotteryContext));//選中獎(jiǎng)池 Award award = awardPool.randomChooseAward();//選中獎(jiǎng)品 return buildIssueResponse(awardSendService.sendAward(award, lotteryContext));//發(fā)出獎(jiǎng)品實(shí)體 } private IssueResponse buildIssueResponse(AwardSendResponse awardSendResponse) {...} }數(shù)據(jù)流轉(zhuǎn)
[圖片上傳失敗...(image-32b3d5-1634801926133)]
在抽獎(jiǎng)平臺(tái)的實(shí)踐中，我們的數(shù)據(jù)流轉(zhuǎn)如上圖所示。 首先領(lǐng)域的開放服務(wù)通過信息傳輸對(duì)象（DTO）來完成與外界的數(shù)據(jù)交互；在領(lǐng)域內(nèi)部，我們通過領(lǐng)域?qū)ο螅―O）作為領(lǐng)域內(nèi)部的數(shù)據(jù)和行為載體；在資源庫內(nèi)部，我們沿襲了原有的數(shù)據(jù)庫持久化對(duì)象（PO）進(jìn)行數(shù)據(jù)庫資源的交互。同時(shí)，DTO與DO的轉(zhuǎn)換發(fā)生在領(lǐng)域服務(wù)內(nèi)，DO與PO的轉(zhuǎn)換發(fā)生在資源庫內(nèi)。
與以往的業(yè)務(wù)服務(wù)相比，當(dāng)前的編碼規(guī)范可能多造成了一次數(shù)據(jù)轉(zhuǎn)換，但每種數(shù)據(jù)對(duì)象職責(zé)明確，數(shù)據(jù)流轉(zhuǎn)更加清晰。
上下文集成
通常集成上下文的手段有多種，常見的手段包括開放領(lǐng)域服務(wù)接口、開放HTTP服>務(wù)以及消息發(fā)布-訂閱機(jī)制。
在抽獎(jiǎng)系統(tǒng)中，我們使用的是開放服務(wù)接口進(jìn)行交互的。最明顯的體現(xiàn)是計(jì)數(shù)上下文，它作為一個(gè)通用上下文，對(duì)抽獎(jiǎng)、風(fēng)控、活動(dòng)準(zhǔn)入等上下文都提供了訪問接口。 同時(shí)，如果在一個(gè)上下文對(duì)另一個(gè)上下文進(jìn)行集成時(shí)，若需要一定的隔離和適配，可以引入防腐層的概念。這一部分的示例可以參考前文的防腐層代碼示例。
分離領(lǐng)域
接下來講解在實(shí)施領(lǐng)域模型的過程中，如何應(yīng)用到系統(tǒng)架構(gòu)中。
我們采用的微服務(wù)架構(gòu)風(fēng)格，與Vernon在《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》并不太一致，更具體差異可閱讀他的書體會(huì)。
如果我們維護(hù)一個(gè)從前到后的應(yīng)用系統(tǒng)：
下圖中領(lǐng)域服務(wù)是使用微服務(wù)技術(shù)剝離開來，獨(dú)立部署，對(duì)外暴露的只能是服務(wù)接口，領(lǐng)域?qū)ν獗┞兜臉I(yè)務(wù)邏輯只能依托于領(lǐng)域服務(wù)。而在Vernon著作中，并未假定微服務(wù)架構(gòu)風(fēng)格，因此領(lǐng)域?qū)颖┞兜某祟I(lǐng)域服務(wù)外，還有聚合、實(shí)體和值對(duì)象等。此時(shí)的應(yīng)用服務(wù)層是比較簡(jiǎn)單的，獲取來自接口層的請(qǐng)求參數(shù)，調(diào)度多個(gè)領(lǐng)域服務(wù)以實(shí)現(xiàn)界面層功能。
[圖片上傳失敗...(image-c1e1c4-1634801926133)]
隨著業(yè)務(wù)發(fā)展，業(yè)務(wù)系統(tǒng)快速膨脹，我們的系統(tǒng)屬于核心時(shí)：
應(yīng)用服務(wù)雖然沒有領(lǐng)域邏輯，但涉及到了對(duì)多個(gè)領(lǐng)域服務(wù)的編排。當(dāng)業(yè)務(wù)規(guī)模龐大到一定程度，編排本身就富含了業(yè)務(wù)邏輯（除此之外，應(yīng)用服務(wù)在穩(wěn)定性、性能上所做的措施也希望統(tǒng)一起來，而非散落各處），那么此時(shí)應(yīng)用服務(wù)對(duì)于外部來說是一個(gè)領(lǐng)域服務(wù)，整體看起來則是一個(gè)獨(dú)立的限界上下文。
此時(shí)應(yīng)用服務(wù)對(duì)內(nèi)還屬于應(yīng)用服務(wù)，對(duì)外已是領(lǐng)域服務(wù)的概念，需要將其暴露為微服務(wù)。
[圖片上傳失敗...(image-325711-1634801926133)]
注：具體的架構(gòu)實(shí)踐可按照?qǐng)F(tuán)隊(duì)和業(yè)務(wù)的實(shí)際情況來，此處僅為作者自身的業(yè)務(wù)實(shí)踐。除分層架構(gòu)外，如CQRS架構(gòu)也是不錯(cuò)的選擇以下是一個(gè)示例。我們定義了抽獎(jiǎng)、活動(dòng)準(zhǔn)入、風(fēng)險(xiǎn)控制等多個(gè)領(lǐng)域服務(wù)。在本系統(tǒng)中，我們需要集成多個(gè)領(lǐng)域服務(wù)，為客戶端提供一套功能完備的抽獎(jiǎng)應(yīng)用服務(wù)。這個(gè)應(yīng)用服務(wù)的組織如下：
package ...; import ...; @Service public class LotteryApplicationService { @Autowired private LotteryRiskService riskService; @Autowired private LotteryConditionService conditionService; @Autowired private LotteryService lotteryService; //用戶參與抽獎(jiǎng)活動(dòng) public Response<PrizeInfo, ErrorData> participateLottery(LotteryContext lotteryContext) { //校驗(yàn)用戶登錄信息 validateLoginInfo(lotteryContext); //校驗(yàn)風(fēng)控 RiskAccessToken riskToken = riskService.accquire(buildRiskReq(lotteryContext)); ... //活動(dòng)準(zhǔn)入檢查 LotteryConditionResult conditionResult = conditionService.checkLotteryCondition(otteryContext.getLotteryId(),lotteryContext.getUserId()); ... //抽獎(jiǎng)并返回結(jié)果 IssueResponse issueResponse = lotteryService.issurLottery(lotteryContext); if(issueResponse!=null && issueResponse.getCode()==IssueResponse.OK) { return buildSuccessResponse(issueResponse.getPrizeInfo()); } else { return buildErrorResponse(ResponseCode.ISSUE_LOTTERY_FAIL, ResponseMsg.ISSUE_LOTTERY_FAIL) } } private void validateLoginInfo(LotteryContext lotteryContext){...} private Response<PrizeInfo, ErrorData> buildErrorResponse (int code, String msg){...} private Response<PrizeInfo, ErrorData> buildSuccessResponse (PrizeInfo prizeInfo){...} }在本文中，我們采用了分治的思想，從抽象到具體闡述了DDD在互聯(lián)網(wǎng)真實(shí)業(yè)務(wù)系統(tǒng)中的實(shí)踐。通過領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這個(gè)強(qiáng)大的武器，我們將系統(tǒng)解構(gòu)的更加合理。
但值得注意的是，如果你面臨的系統(tǒng)很簡(jiǎn)單或者做一些SmartUI之類，那么你不一定需要DDD。盡管本文對(duì)貧血模型、演進(jìn)式設(shè)計(jì)提出了些許看法，但它們?cè)谔囟ǚ秶途唧w場(chǎng)景下會(huì)更高效。讀者需要針對(duì)自己的實(shí)際情況，做一定取舍，適合自己的才是最好的。
本篇通過DDD來講述軟件設(shè)計(jì)的術(shù)與器，本質(zhì)是為了高內(nèi)聚低耦合，緊靠本質(zhì)，按自己的理解和團(tuán)隊(duì)情況來實(shí)踐DDD即可。
