領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)架構(gòu)的實(shí)踐

1、 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）架構(gòu)的實(shí)踐前言至少30年以前，一些軟件設(shè)計(jì)人員就已經(jīng)意識(shí)到領(lǐng)域建模和設(shè)計(jì)的重要性，并形成一種思潮，Eric Evans將其定義為領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，簡稱DDD）。在互聯(lián)網(wǎng)開發(fā)“小步快跑，迭代試錯(cuò)”的大環(huán)境下，DDD似乎是一種比較“古老而緩慢”的思想。然而，由于互聯(lián)網(wǎng)公司也逐漸深入實(shí)體經(jīng)濟(jì)，業(yè)務(wù)日益復(fù)雜，我們?cè)陂_發(fā)中也越來越多地遇到傳統(tǒng)行業(yè)軟件開發(fā)中所面臨的問題。本文就先來講一下這些問題，然后再嘗試在實(shí)踐中用DDD的思想來解決這些問題。問題過度耦合業(yè)務(wù)初期，我們的功能大都非常簡單，普通的CRUD就能滿足，此時(shí)系統(tǒng)是清晰的。隨著迭代的不斷

2、演化，業(yè)務(wù)邏輯變得越來越復(fù)雜，我們的系統(tǒng)也越來越冗雜。模塊彼此關(guān)聯(lián)，誰都很難說清模塊的具體功能意圖是啥。修改一個(gè)功能時(shí)，往往光回溯該功能需要的修改點(diǎn)就需要很長時(shí)間，更別提修改帶來的不可預(yù)知的影響面。下圖是一個(gè)常見的系統(tǒng)耦合病例。訂單服務(wù)接口中提供了查詢、創(chuàng)建訂單相關(guān)的接口，也提供了訂單評(píng)價(jià)、支付、保險(xiǎn)的接口。同時(shí)我們的表也是一個(gè)訂單大表，包含了非常多字段。在我們維護(hù)代碼時(shí)，牽一發(fā)而動(dòng)全身，很可能只是想改下評(píng)價(jià)相關(guān)的功能，卻影響到了創(chuàng)單核心路徑。雖然我們可以通過測(cè)試保證功能完備性，但當(dāng)我們?cè)谟唵晤I(lǐng)域有大量需求同時(shí)并行開發(fā)時(shí)，改動(dòng)重疊、惡性循環(huán)、疲于奔命修改各種問題。上述問題，歸根到底在于系統(tǒng)架構(gòu)

3、不清晰，劃分出來的模塊內(nèi)聚度低、高耦合。有一種解決方案，按照演進(jìn)式設(shè)計(jì)的理論，讓系統(tǒng)的設(shè)計(jì)隨著系統(tǒng)實(shí)現(xiàn)的增長而增長。我們不需要作提前設(shè)計(jì)，就讓系統(tǒng)伴隨業(yè)務(wù)成長而演進(jìn)。這當(dāng)然是可行的，敏捷實(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í)踐中，重構(gòu)是克服演進(jìn)式設(shè)計(jì)中大雜燴問題的主力，通過在單獨(dú)的類及方法級(jí)別上做一系列小步重構(gòu)來完成。我們可以很容易重構(gòu)出一個(gè)獨(dú)立的類來放某些通用的邏輯，但是你會(huì)發(fā)現(xiàn)你很難給它一個(gè)業(yè)務(wù)上的含義，只能給予一個(gè)技

4、術(shù)維度描繪的含義。這會(huì)帶來什么問題呢？新同學(xué)并不總是知道對(duì)通用邏輯的改動(dòng)或獲取來自該類。顯然，制定項(xiàng)目規(guī)范并不是好的idea。我們又聞到了代碼即將腐敗的味道。事實(shí)上，你可能意識(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è)計(jì)似乎變成了重構(gòu)者的自娛自樂，代碼繼續(xù)腐敗，重新重構(gòu)無休止的循環(huán)。用DDD則可以很好地解決領(lǐng)域模型到設(shè)計(jì)模型的同步、演化，最后再將反映了領(lǐng)域的

5、設(shè)計(jì)模型轉(zhuǎn)為實(shí)際的代碼。注：模型是我們解決實(shí)際問題所抽象出來的概念模型，領(lǐng)域模型則表達(dá)與業(yè)務(wù)相關(guān)的事實(shí)；設(shè)計(jì)模型則描述了所要構(gòu)建的系統(tǒng)。貧血癥和失憶癥貧血領(lǐng)域?qū)ο筘氀I(lǐng)域?qū)ο螅ˋnemic Domain Object）是指僅用作數(shù)據(jù)載體，而沒有行為和動(dòng)作的領(lǐng)域?qū)ο?。在我們?xí)慣了J2EE的開發(fā)模式后，Action/Service/DAO這種分層模式，會(huì)很自然地寫出過程式代碼，而學(xué)到的很多關(guān)于OO理論的也毫無用武之地。使用這種開發(fā)方式，對(duì)象只是數(shù)據(jù)的載體，沒有行為。以數(shù)據(jù)為中心，以數(shù)據(jù)庫ER設(shè)計(jì)作驅(qū)動(dòng)。分層架構(gòu)在這種開發(fā)模式下，可以理解為是對(duì)數(shù)據(jù)移動(dòng)、處理和實(shí)現(xiàn)的過程。以筆者最近開發(fā)的系統(tǒng)抽獎(jiǎng)平臺(tái)

6、為例：場(chǎng)景需求獎(jiǎng)池里配置了很多獎(jiǎng)項(xiàng)，我們需要按運(yùn)營預(yù)先配置的概率抽中一個(gè)獎(jiǎng)項(xiàng)。實(shí)現(xiàn)非常簡單，生成一個(gè)隨機(jī)數(shù)，匹配符合該隨機(jī)數(shù)生成概率的獎(jiǎng)項(xiàng)即可。貧血模型實(shí)現(xiàn)方案先設(shè)計(jì)獎(jiǎng)池和獎(jiǎng)項(xiàng)的庫表配置。設(shè)計(jì)AwardPool和Award兩個(gè)對(duì)象，只有簡單的get和set屬性的方法class AwardPool int awardPoolId; List awards; public List getAwards() return awards; public void setAwards(List awards) this.awards = awards; class Award int awardId;

7、int probability;/概率 Service代碼實(shí)現(xiàn)設(shè)計(jì)一個(gè)LotteryService，在其中的drawLottery()方法寫服務(wù)邏輯AwardPool awardPool = awardPoolDao.getAwardPool(poolId);/sql查詢，將數(shù)據(jù)映射到AwardPool對(duì)象for (Award award : awardPool.getAwards() /尋找到符合award.getProbability()概率的award按照我們通常思路實(shí)現(xiàn)，可以發(fā)現(xiàn)：在業(yè)務(wù)領(lǐng)域里非常重要的抽獎(jiǎng)，我的業(yè)務(wù)邏輯都是寫在Service中的，Award充其量只是個(gè)數(shù)據(jù)載體，沒有任

8、何行為。簡單的業(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ū)ο笾?。繼續(xù)舉我們上述抽獎(jiǎng)的例子，使用概率選擇對(duì)應(yīng)的獎(jiǎng)品就應(yīng)當(dāng)放到AwardPool類中。為什么選擇DDD軟件系統(tǒng)復(fù)雜性應(yīng)對(duì)解決復(fù)雜和大規(guī)模軟件的武器可以被粗略地歸為三類：抽象、分治和知識(shí)。分治把問題空間分割為規(guī)模更小且易于處理的若干子問題。分割后的問題需要足夠小，以便一個(gè)人單槍

9、匹馬就能夠解決他們；其次，必須考慮如何將分割后的各個(gè)部分裝配為整體。分割得越合理越易于理解，在裝配成整體時(shí)，所需跟蹤的細(xì)節(jié)也就越少。即更容易設(shè)計(jì)各部分的協(xié)作方式。評(píng)判什么是分治得好，即高內(nèi)聚低耦合。抽象使用抽象能夠精簡問題空間，而且問題越小越容易理解。舉個(gè)例子，從北京到上海出差，可以先理解為使用交通工具前往，但不需要一開始就想清楚到底是高鐵還是飛機(jī)，以及乘坐他們需要注意什么。知識(shí)顧名思義，DDD可以認(rèn)為是知識(shí)的一種。DDD提供了這樣的知識(shí)手段，讓我們知道如何抽象出限界上下文以及如何去分治。與微服務(wù)架構(gòu)相得益彰微服務(wù)架構(gòu)眾所周知，此處不做贅述。我們創(chuàng)建微服務(wù)時(shí)，需要?jiǎng)?chuàng)建一個(gè)高內(nèi)聚、低耦合的微服務(wù)

10、。而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)一，那么在具體做法上有什么聯(lián)系和不同呢？我們將架構(gòu)設(shè)計(jì)活動(dòng)精簡為以下三個(gè)層面：業(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ā)中

11、是有先后順序的，但不一定孰先孰后。在我們解決常規(guī)套路問題時(shí)，我們會(huì)很自然地往熟悉的分層架構(gòu)套（先確定系統(tǒng)架構(gòu)），或者用PHP開發(fā)很快（先確定技術(shù)架構(gòu)），在業(yè)務(wù)不復(fù)雜時(shí)，這樣是合理的。跳過業(yè)務(wù)架構(gòu)設(shè)計(jì)出來的架構(gòu)關(guān)注點(diǎn)不在業(yè)務(wù)響應(yīng)上，可能就是個(gè)大泥球，在面臨需求迭代或響應(yīng)市場(chǎng)變化時(shí)就很痛苦。DDD的核心訴求就是將業(yè)務(wù)架構(gòu)映射到系統(tǒng)架構(gòu)上，在響應(yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)時(shí)，也隨之變化系統(tǒng)架構(gòu)。而微服務(wù)追求業(yè)務(wù)層面的復(fù)用，設(shè)計(jì)出來的系統(tǒng)架構(gòu)和業(yè)務(wù)一致；在技術(shù)架構(gòu)上則系統(tǒng)模塊之間充分解耦，可以自由地選擇合適的技術(shù)架構(gòu)，去中心化地治理技術(shù)和數(shù)據(jù)。可以參見下圖來更好地理解雙方之間的協(xié)作關(guān)系：如何實(shí)踐DDD我們將

12、通過上文提到的抽獎(jiǎng)平臺(tái)，來詳細(xì)介紹我們?nèi)绾瓮ㄟ^DDD來解構(gòu)一個(gè)中型的基于微服務(wù)架構(gòu)的系統(tǒng)，從而做到系統(tǒng)的高內(nèi)聚、低耦合。首先看下抽獎(jiǎng)系統(tǒng)的大致需求：運(yùn)營可以配置一個(gè)抽獎(jiǎng)活動(dòng)，該活動(dòng)面向一個(gè)特定的用戶群體，并針對(duì)一個(gè)用戶群體發(fā)放一批不同類型的獎(jiǎng)品（優(yōu)惠券，激活碼，實(shí)物獎(jiǎng)品等）。用戶-通過活動(dòng)頁面參與不同類型的抽獎(jiǎng)活動(dòng)。設(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í)踐中

13、檢驗(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)。在邊界內(nèi)，每一個(gè)模型概念，包括它的屬性和操作，都具有特殊的含義。一個(gè)給定的業(yè)務(wù)領(lǐng)域會(huì)包含多個(gè)限界上下文，想與一個(gè)限界上下文溝通，則需要通過顯示

14、邊界進(jìn)行通信。系統(tǒng)通過確定的限界上下文來進(jìn)行解耦，而每一個(gè)上下文內(nèi)部緊密組織，職責(zé)明確，具有較高的內(nèi)聚性。一個(gè)很形象的隱喻：細(xì)胞質(zhì)所以能夠存在，是因?yàn)榧?xì)胞膜限定了什么在細(xì)胞內(nèi)，什么在細(xì)胞外，并且確定了什么物質(zhì)可以通過細(xì)胞膜。劃分限界上下文劃分限界上下文，不管是Eric Evans還是Vaughn Vernon，在他們的大作里都沒有怎么提及。顯然我們不應(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)系；我們將緊耦合的各自圈在一起，觀察他們

15、內(nèi)在的聯(lián)系，從而形成對(duì)應(yīng)的界限上下文。形成之后，我們可以嘗試用語言來描述下界限上下文的職責(zé)，看它是否清晰、準(zhǔn)確、簡潔和完整。簡言之，限界上下文應(yīng)該從需求出發(fā)，按領(lǐng)域劃分。前文提到，我們的用戶劃分為運(yùn)營和用戶。其中，運(yùn)營對(duì)抽獎(jiǎng)活動(dòng)的配置十分復(fù)雜但相對(duì)低頻。用戶對(duì)這些抽獎(jiǎng)活動(dòng)配置的使用是高頻次且無感知的。根據(jù)這樣的業(yè)務(wù)特點(diǎn)，我們首先將抽獎(jiǎng)平臺(tái)劃分為C端抽獎(jiǎng)和M端抽獎(jiǎng)管理平臺(tái)兩個(gè)子域，讓兩者完全解耦。在確認(rèn)了M端領(lǐng)域和C端的限界上下文后，我們?cè)賹?duì)各自上下文內(nèi)部進(jìn)行限界上下文的劃分。下面我們用C端進(jìn)行舉例。產(chǎn)品的需求概述如下：1. 抽獎(jiǎng)活動(dòng)有活動(dòng)限制，例如用戶的抽獎(jiǎng)次數(shù)限制，抽獎(jiǎng)的開始和結(jié)束的時(shí)間等；

16、2. 一個(gè)抽獎(jiǎng)活動(dòng)包含多個(gè)獎(jiǎng)品，可以針對(duì)一個(gè)或多個(gè)用戶群體；3. 獎(jiǎng)品有自身的獎(jiǎng)品配置，例如庫存量，被抽中的概率等，最多被一個(gè)用戶抽中的次數(shù)等等；4. 用戶群體有多種區(qū)別方式，如按照用戶所在城市區(qū)分，按照新老客區(qū)分等；5. 活動(dòng)具有風(fēng)控配置，能夠限制用戶參與抽獎(jiǎng)的頻率。根據(jù)產(chǎn)品的需求，我們提取了一些關(guān)鍵性的概念作為子域，形成我們的限界上下文。首先，抽獎(jiǎng)上下文作為整個(gè)領(lǐng)域的核心，承擔(dān)著用戶抽獎(jiǎng)的核心業(yè)務(wù)，抽獎(jiǎng)中包含了獎(jiǎng)品和用戶群體的概念。在設(shè)計(jì)初期，我們?cè)?jīng)考慮劃分出抽獎(jiǎng)和發(fā)獎(jiǎng)兩個(gè)領(lǐng)域，前者負(fù)責(zé)選獎(jiǎng)，后者負(fù)責(zé)將選中的獎(jiǎng)品發(fā)放出去。但在實(shí)際開發(fā)過程中，我們發(fā)現(xiàn)這兩部分的邏輯緊密連接，難以拆分。并且

17、單純的發(fā)獎(jiǎng)邏輯足夠簡單，僅僅是調(diào)用第三方服務(wù)進(jìn)行發(fā)獎(jiǎng)，不足以獨(dú)立出來成為一個(gè)領(lǐng)域。對(duì)于活動(dòng)的限制，我們定義了活動(dòng)準(zhǔn)入的通用語言，將活動(dòng)開始/結(jié)束時(shí)間，活動(dòng)可參與次數(shù)等限制條件都收攏到活動(dòng)準(zhǔn)入上下文中。對(duì)于抽獎(jiǎng)的獎(jiǎng)品庫存量，由于庫存的行為與獎(jiǎng)品本身相對(duì)解耦，庫存關(guān)注點(diǎn)更多是庫存內(nèi)容的核銷，且?guī)齑姹旧砭邆渫ㄓ眯?，可以被?jiǎng)品之外的內(nèi)容使用，因此我們定義了獨(dú)立的庫存上下文。由于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ì)數(shù)上下文?？梢钥吹?，通過DDD的限界上下文劃分，我們界定出抽獎(jiǎng)、活動(dòng)準(zhǔn)入、風(fēng)控、

18、計(jì)數(shù)、庫存等五個(gè)上下文，每個(gè)上下文在系統(tǒng)中都高度內(nèi)聚。上下文映射圖在進(jìn)行上下文劃分之后，我們還需要進(jìn)一步梳理上下文之間的關(guān)系?？低窢柨低┒扇魏谓M織在設(shè)計(jì)一套系統(tǒng)（廣義概念上的系統(tǒng)）時(shí)，所交付的設(shè)計(jì)方案在結(jié)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致?？低筛嬖V我們，系統(tǒng)結(jié)構(gòu)應(yīng)盡量的與組織結(jié)構(gòu)保持一致。這里，我們認(rèn)為團(tuán)隊(duì)結(jié)構(gòu)（無論是內(nèi)部組織還是團(tuán)隊(duì)間組織）就是組織結(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è)上下文可以明確

19、自己對(duì)其他上下文的依賴關(guān)系，從而使得團(tuán)隊(duì)內(nèi)開發(fā)直接更好的對(duì)接。從團(tuán)隊(duì)間的關(guān)系來看，明確的上下文關(guān)系能夠帶來如下幫助：每個(gè)團(tuán)隊(duì)在它的上下文中能夠更加明確自己領(lǐng)域內(nèi)的概念，因?yàn)樯舷挛氖穷I(lǐng)域的解系統(tǒng)；對(duì)于限界上下文之間發(fā)生交互，團(tuán)隊(duì)與上下文的一致性，能夠保證我們明確對(duì)接的團(tuán)隊(duì)和依賴的上下游。限界上下文之間的映射關(guān)系合作關(guān)系（Partnership）：兩個(gè)上下文緊密合作的關(guān)系，一榮俱榮，一損俱損。共享內(nèi)核（Shared Kernel）：兩個(gè)上下文依賴部分共享的模型?？蛻舴?供應(yīng)方開發(fā)（Customer-Supplier Development）：上下文之間有組織的上下游依賴。遵奉者（Conformis

20、t）：下游上下文只能盲目依賴上游上下文。防腐層（Anticorruption Layer）：一個(gè)上下文通過一些適配和轉(zhuǎn)換與另一個(gè)上下文交互。開放主機(jī)服務(wù)（Open Host Service）：定義一種協(xié)議來讓其他上下文來對(duì)本上下文進(jìn)行訪問。發(fā)布語言（Published Language）：通常與OHS一起使用，用于定義開放主機(jī)的協(xié)議。大泥球（Big Ball of Mud）：混雜在一起的上下文關(guān)系，邊界不清晰。另謀他路（SeparateWay）：兩個(gè)完全沒有任何聯(lián)系的上下文。上文定義了上下文映射間的關(guān)系，經(jīng)過我們的反復(fù)斟酌，抽獎(jiǎng)平臺(tái)上下文的映射關(guān)系圖如下：由于抽獎(jiǎng)，風(fēng)控，活動(dòng)準(zhǔn)入，庫存，計(jì)數(shù)五

21、個(gè)上下文都處在抽獎(jiǎng)?lì)I(lǐng)域的內(nèi)部，所以它們之間符合“一榮俱榮，一損俱損”的合作關(guān)系（PartnerShip，簡稱PS）。同時(shí)，抽獎(jiǎng)上下文在進(jìn)行發(fā)券動(dòng)作時(shí)，會(huì)依賴券碼、平臺(tái)券、外賣券三個(gè)上下文。抽獎(jiǎng)上下文通過防腐層（Anticorruption Layer，ACL）對(duì)三個(gè)上下文進(jìn)行了隔離，而三個(gè)券上下文通過開放主機(jī)服務(wù)（Open Host Service）作為發(fā)布語言（Published Language）對(duì)抽獎(jiǎng)上下文提供訪問機(jī)制。通過上下文映射關(guān)系，我們明確的限制了限界上下文的耦合性，即在抽獎(jiǎng)平臺(tái)中，無論是上下文內(nèi)部交互（合作關(guān)系）還是與外部上下文交互（防腐層），耦合度都限定在數(shù)據(jù)耦合（Data

22、Coupling）的層級(jí)。戰(zhàn)術(shù)建模細(xì)化上下文梳理清楚上下文之間的關(guān)系后，我們需要從戰(zhàn)術(shù)層面上剖析上下文內(nèi)部的組織關(guān)系。首先看下DDD中的一些定義。實(shí)體當(dāng)一個(gè)對(duì)象由其標(biāo)識(shí)（而不是屬性）區(qū)分時(shí)，這種對(duì)象稱為實(shí)體（Entity）。例：最簡單的，公安系統(tǒng)的身份信息錄入，對(duì)于人的模擬，即認(rèn)為是實(shí)體，因?yàn)槊總€(gè)人是獨(dú)一無二的，且其具有唯一標(biāo)識(shí)（如公安系統(tǒng)分發(fā)的身份證號(hào)碼）。在實(shí)踐上建議將屬性的驗(yàn)證放到實(shí)體中。值對(duì)象當(dāng)一個(gè)對(duì)象用于對(duì)事務(wù)進(jìn)行描述而沒有唯一標(biāo)識(shí)時(shí)，它被稱作值對(duì)象（Value Object）。例：比如顏色信息，我們只需要知道name:黑色，css:#000000這樣的值信息就能夠滿足要求了，這避免

23、了我們對(duì)標(biāo)識(shí)追蹤帶來的系統(tǒng)復(fù)雜性。值對(duì)象很重要，在習(xí)慣了使用數(shù)據(jù)庫的數(shù)據(jù)建模后，很容易將所有對(duì)象看作實(shí)體。使用值對(duì)象，可以更好地做系統(tǒng)優(yōu)化、精簡設(shè)計(jì)。它具有不變性、相等性和可替換性。在實(shí)踐中，需要保證值對(duì)象創(chuàng)建后就不能被修改，即不允許外部再修改其屬性。在不同上下文集成時(shí)，會(huì)出現(xiàn)模型概念的公用，如商品模型會(huì)存在于電商的各個(gè)上下文中。在訂單上下文中如果你只關(guān)注下單時(shí)商品信息快照，那么將商品對(duì)象視為值對(duì)象是很好的選擇。聚合根Aggregate(聚合）是一組相關(guān)對(duì)象的集合，作為一個(gè)整體被外界訪問，聚合根（Aggregate Root）是這個(gè)聚合的根節(jié)點(diǎn)。聚合是一個(gè)非常重要的概念，核心領(lǐng)域往往都需要用聚

24、合來表達(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)建

25、邏輯。聚合內(nèi)部多個(gè)組成對(duì)象的關(guān)系可以用來指導(dǎo)數(shù)據(jù)庫創(chuàng)建，但不可避免存在一定的抗阻。如聚合中存在List，那么在數(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)上下文的建模。在抽獎(jiǎng)上下文中，我們通過抽獎(jiǎng)(DrawLottery

26、)這個(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型。D

27、DD工程實(shí)現(xiàn)在對(duì)上下文進(jìn)行細(xì)化后，我們開始在工程中真正落地DDD。模塊模塊（Module）是DDD中明確提到的一種控制限界上下文的手段，在我們的工程中，一般盡量用一個(gè)模塊來表示一個(gè)領(lǐng)域的限界上下文。如代碼中所示，一般的工程中包的組織方式為com.公司名.組織架構(gòu).業(yè)務(wù).上下文.*，這樣的組織結(jié)構(gòu)能夠明確的將一個(gè)上下文限定在包的內(nèi)部。代碼演示1 模塊的組織對(duì)于模塊內(nèi)的組織結(jié)構(gòu)，一般情況下我們是按照領(lǐng)域?qū)ο?、領(lǐng)域服務(wù)、領(lǐng)域資源庫、防腐層等組織方式定義的。代碼演示2 模塊的組織每個(gè)模塊的具體實(shí)現(xiàn)，我們將在下文中展開。領(lǐng)域?qū)ο笄拔奶岬剑I(lǐng)域驅(qū)動(dòng)要解決的一個(gè)重要的問題，就是解決對(duì)象的貧血問題。這里我們用

28、之前定義的抽獎(jiǎng)（DrawLottery）聚合根和獎(jiǎng)池（AwardPool）值對(duì)象來具體說明。抽獎(jiǎng)聚合根持有了抽獎(jiǎng)活動(dòng)的id和該活動(dòng)下的所有可用獎(jiǎng)池列表，它的一個(gè)最主要的領(lǐng)域功能就是根據(jù)一個(gè)抽獎(jiǎng)發(fā)生場(chǎng)景（DrawLotteryContext），選擇出一個(gè)適配的獎(jiǎng)池，即chooseAwardPool方法。chooseAwardPool的邏輯是這樣的：DrawLotteryContext會(huì)帶有用戶抽獎(jiǎng)時(shí)的場(chǎng)景信息（抽獎(jiǎng)得分或抽獎(jiǎng)時(shí)所在的城市），DrawLottery會(huì)根據(jù)這個(gè)場(chǎng)景信息，匹配一個(gè)可以給用戶發(fā)獎(jiǎng)的AwardPool。代碼演示3 DrawLottery在匹配到一個(gè)具體的獎(jiǎng)池之后，需要確定最

29、后給用戶的獎(jiǎng)品是什么。這部分的領(lǐng)域功能在AwardPool內(nèi)。代碼演示4 AwardPool與以往的僅有g(shù)etter、setter的業(yè)務(wù)對(duì)象不同，領(lǐng)域?qū)ο缶哂辛诵袨?，?duì)象更加豐滿。同時(shí)，比起將這些邏輯寫在服務(wù)內(nèi)（例如*Service），領(lǐng)域功能的內(nèi)聚性更強(qiáng)，職責(zé)更加明確。資源庫領(lǐng)域?qū)ο笮枰Y源存儲(chǔ)，存儲(chǔ)的手段可以是多樣化的，常見的無非是數(shù)據(jù)庫，分布式緩存，本地緩存等。資源庫（Repository）的作用，就是對(duì)領(lǐng)域的存儲(chǔ)和訪問進(jìn)行統(tǒng)一管理的對(duì)象。在抽獎(jiǎng)平臺(tái)中，我們是通過如下的方式組織資源庫的。代碼演示5 Repository組織結(jié)構(gòu)資源庫對(duì)外的整體訪問由Repository提供，它聚合了各個(gè)資

30、源庫的數(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ù)中的做法，由資源庫對(duì)資源進(jìn)行管理，職責(zé)更加明確，代碼的可讀性和可維護(hù)性也更強(qiáng)。代碼演示6 DrawLotteryRepository防腐層亦稱適配層。在一個(gè)上下文中，有時(shí)需要對(duì)外部上下文進(jìn)行訪問，通常會(huì)引入防腐層的概念來對(duì)外部上下文的訪問進(jìn)行一次轉(zhuǎn)義。有以下幾種情況會(huì)考慮引入防腐層：需要將外部上下文中的模型翻譯成本上下文理解的模型。

31、不同上下文之間的團(tuán)隊(duì)協(xié)作關(guān)系，如果是供奉者關(guān)系，建議引入防腐層，避免外部上下文變化對(duì)本上下文的侵蝕。該訪問本上下文使用廣泛，為了避免改動(dòng)影響范圍過大。如果內(nèi)部多個(gè)上下文對(duì)外部上下文需要訪問，那么可以考慮將其放到通用上下文中。在抽獎(jiǎng)平臺(tái)中，我們定義了用戶城市信息防腐層(UserCityInfoFacade)，用于外部的用戶城市信息上下文（微服務(wù)架構(gòu)下表現(xiàn)為用戶城市信息服務(wù)）。以用戶信息防腐層舉例，它以抽獎(jiǎng)?wù)埱髤?shù)(LotteryContext)為入?yún)?，以城市信?MtCityInfo)為輸出。代碼演示7 UserCityInfoFacade領(lǐng)域服務(wù)上文中，我們將領(lǐng)域行為封裝到領(lǐng)域?qū)ο笾?，將資源管

32、理行為封裝到資源庫中，將外部上下文的交互行為封裝到防腐層中。此時(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)足夠清晰明了。代碼演示8 LotteryService數(shù)據(jù)流轉(zhuǎn)在抽獎(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ù)接口、開放H