點(diǎn)擊“技術(shù)領(lǐng)導(dǎo)力”關(guān)注???每天早上8:30推送

來源：美團(tuán)技術(shù)團(tuán)隊(duì)

至少30年以前，一些軟件設(shè)計(jì)人員就已經(jīng)意識(shí)到領(lǐng)域建模和設(shè)計(jì)的重要性，并形成一種思潮，Eric Evans將其定義為領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，簡(jiǎn)稱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ù)初期，我們的功能大都非常簡(jiǎn)單，普通的CRUD就能滿足，此時(shí)系統(tǒng)是清晰的。隨著迭代的不斷演化，業(yè)務(wù)邏輯變得越來越復(fù)雜，我們的系統(tǒng)也越來越冗雜。模塊彼此關(guān)聯(lián)，誰都很難說清模塊的具體功能意圖是啥。修改一個(gè)功能時(shí)，往往光回溯該功能需要的修改點(diǎn)就需要很長(zhǎng)時(shí)間，更別提修改帶來的不可預(yù)知的影響面。

下圖是一個(gè)常見的系統(tǒng)耦合病例。

服務(wù)耦合示意圖

訂單服務(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)不清晰，劃分出來的模塊內(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)。這當(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ì)提供了同一代碼庫(kù)。

在這三種實(shí)踐中，重構(gòu)是克服演進(jìn)式設(shè)計(jì)中大雜燴問題的主力，通過在單獨(dú)的類及方法級(jí)別上做一系列小步重構(gòu)來完成。我們可以很容易重構(gòu)出一個(gè)獨(dú)立的類來放某些通用的邏輯，但是你會(huì)發(fā)現(xiàn)你很難給它一個(gè)業(yè)務(wù)上的含義，只能給予一個(gè)技術(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)域的設(shè)計(jì)模型轉(zhuǎn)為實(shí)際的代碼。

注：模型是我們解決實(shí)際問題所抽象出來的概念模型，領(lǐng)域模型則表達(dá)與業(yè)務(wù)相關(guān)的事實(shí)；設(shè)計(jì)模型則描述了所要構(gòu)建的系統(tǒng)。

貧血癥和失憶癥

貧血領(lǐng)域?qū)ο?#xff08;Anemic Domain Object）是指僅用作數(shù)據(jù)載體，而沒有行為和動(dòng)作的領(lǐng)域?qū)ο蟆?/p>

在我們習(xí)慣了J2EE的開發(fā)模式后，Action/Service/DAO這種分層模式，會(huì)很自然地寫出過程式代碼，而學(xué)到的很多關(guān)于OO理論的也毫無用武之地。使用這種開發(fā)方式，對(duì)象只是數(shù)據(jù)的載體，沒有行為。以數(shù)據(jù)為中心，以數(shù)據(jù)庫(kù)ER設(shè)計(jì)作驅(qū)動(dòng)。分層架構(gòu)在這種開發(fā)模式下，可以理解為是對(duì)數(shù)據(jù)移動(dòng)、處理和實(shí)現(xiàn)的過程。

以筆者最近開發(fā)的系統(tǒng)抽獎(jiǎng)平臺(tái)為例：

場(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)的庫(kù)表配置。

抽獎(jiǎng)ER圖

設(shè)計(jì)AwardPool和Award兩個(gè)對(duì)象，只有簡(jiǎn)單的get和set屬性的方法：

classAwardPool{

int awardPoolId;

List<Award> awards;

publicList<Award> getAwards() {

return awards;

}

publicvoid setAwards(List<Award> awards) {

this.awards = awards;

}

......

}

classAward{

int awardId;

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ù)載體，沒有任何行為。簡(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ū)ο笾小＠^續(xù)舉我們上述抽獎(jiǎng)的例子，使用概率選擇對(duì)應(yīng)的獎(jiǎng)品就應(yīng)當(dāng)放到AwardPool類中。

軟件系統(tǒng)復(fù)雜性應(yīng)對(duì)

解決復(fù)雜和大規(guī)模軟件的武器可以被粗略地歸為三類：抽象、分治和知識(shí)。

• 分治，把問題空間分割為規(guī)模更小且易于處理的若干子問題。分割后的問題需要足夠小，以便一個(gè)人單槍匹馬就能夠解決他們；其次，必須考慮如何將分割后的各個(gè)部分裝配為整體。分割得越合理越易于理解，在裝配成整體時(shí)，所需跟蹤的細(xì)節(jié)也就越少。即更容易設(shè)計(jì)各部分的協(xié)作方式。評(píng)判什么是分治得好，即高內(nèi)聚低耦合。

• 抽象，使用抽象能夠精簡(jiǎn)問題空間，而且問題越小越容易理解。舉個(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ù)。而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)精簡(jiǎn)為以下三個(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ā)中是有先后順序的，但不一定孰先孰后。在我們解決常規(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)系：

DDD與微服務(wù)關(guān)系

我們將通過上文提到的抽獎(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)營(yíng)——可以配置一個(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ì)倉(cāng)儲(chǔ)，并思考實(shí)體或值對(duì)象的創(chuàng)建方式；

在工程中實(shí)踐領(lǐng)域模型，并在實(shí)踐中檢驗(yàn)?zāi)Ｐ偷暮侠硇?#xff0c;倒推模型中不足的地方并重構(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è)限界上下文溝通，則需要通過顯示邊界進(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)系；我們將緊耦合的各自圈在一起，觀察他們內(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端抽獎(jiǎng)和M端抽獎(jiǎng)管理平臺(tái)兩個(gè)子域，讓兩者完全解耦。

抽獎(jiǎng)平臺(tái)領(lǐng)域

在確認(rèn)了M端領(lǐng)域和C端的限界上下文后，我們?cè)賹?duì)各自上下文內(nèi)部進(jìn)行限界上下文的劃分。下面我們用C端進(jìn)行舉例。

產(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)品配置，例如庫(kù)存量，被抽中的概率等，最多被一個(gè)用戶抽中的次數(shù)等等；

用戶群體有多種區(qū)別方式，如按照用戶所在城市區(qū)分，按照新老客區(qū)分等；

活動(dòng)具有風(fēng)控配置，能夠限制用戶參與抽獎(jiǎng)的頻率。

根據(jù)產(chǎn)品的需求，我們提取了一些關(guān)鍵性的概念作為子域，形成我們的限界上下文。

C端抽獎(jiǎng)?lì)I(lǐng)域

首先，抽獎(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)這兩部分的邏輯緊密連接，難以拆分。并且單純的發(fā)獎(jiǎng)邏輯足夠簡(jiǎn)單，僅僅是調(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)品庫(kù)存量，由于庫(kù)存的行為與獎(jiǎng)品本身相對(duì)解耦，庫(kù)存關(guān)注點(diǎn)更多是庫(kù)存內(nèi)容的核銷，且?guī)齑姹旧砭邆渫ㄓ眯?#xff0c;可以被獎(jiǎng)品之外的內(nèi)容使用，因此我們定義了獨(dú)立的庫(kù)存上下文。

由于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)控、計(jì)數(shù)、庫(kù)存等五個(gè)上下文，每個(gè)上下文在系統(tǒng)中都高度內(nèi)聚。

上下文映射圖

在進(jìn)行上下文劃分之后，我們還需要進(jìn)一步梳理上下文之間的關(guān)系。

康威（梅爾·康威）定律，任何組織在設(shè)計(jì)一套系統(tǒng)（廣義概念上的系統(tǒng)）時(shí)，所交付的設(shè)計(jì)方案在結(jié)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致。

康威定律告訴我們，系統(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è)上下文可以明確自己對(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）：上下文之間有組織的上下游依賴。

• 遵奉者（Conformist）：下游上下文只能盲目依賴上游上下文。

• 防腐層（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)系圖如下：

上下文映射關(guān)系

由于抽獎(jiǎng)，風(fēng)控，活動(dòng)準(zhǔn)入，庫(kù)存，計(jì)數(shù)五個(gè)上下文都處在抽獎(jiǎng)?lì)I(lǐng)域的內(nèi)部，所以它們之間符合“一榮俱榮，一損俱損”的合作關(guān)系（PartnerShip，簡(jiǎn)稱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 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）。

例：最簡(jiǎn)單的，公安系統(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”}這樣的值信息就能夠滿足要求了，這避免了我們對(duì)標(biāo)識(shí)追蹤帶來的系統(tǒng)復(fù)雜性。

值對(duì)象很重要，在習(xí)慣了使用數(shù)據(jù)庫(kù)的數(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è)整體被外界訪問，聚合根（Aggregate Root）是這個(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ù)庫(kù)創(chuàng)建，但不可避免存在一定的抗阻。如聚合中存在List<值對(duì)象>，那么在數(shù)據(jù)庫(kù)中建立1:N的關(guān)聯(lián)需要將值對(duì)象單獨(dú)建表，此時(shí)是有id的，建議不要將該id暴露到資源庫(kù)外部，對(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)上下文中，我們通過抽獎(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)

在對(duì)上下文進(jìn)行細(xì)化后，我們開始在工程中真正落地DDD。

模塊

模塊（Module）是DDD中明確提到的一種控制限界上下文的手段，在我們的工程中，一般盡量用一個(gè)模塊來表示一個(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.*;//庫(kù)存上下文

代碼演示1 模塊的組織

對(duì)于模塊內(nèi)的組織結(jié)構(gòu)，一般情況下我們是按照領(lǐng)域?qū)ο蟆㈩I(lǐng)域服務(wù)、領(lǐng)域資源庫(kù)、防腐層等組織方式定義的。

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)域資源庫(kù)

import com.company.team.bussiness.lottery.facade.*;//領(lǐng)域防腐層

代碼演示2 模塊的組織

每個(gè)模塊的具體實(shí)現(xiàn)，我們將在下文中展開。

領(lǐng)域?qū)ο?/strong>

前文提到，領(lǐng)域驅(qū)動(dòng)要解決的一個(gè)重要的問題，就是解決對(duì)象的貧血問題。這里我們用之前定義的抽獎(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。

package com.company.team.bussiness.lottery.domain.aggregate;

import...;

publicclassDrawLottery{

privateint lotteryId; //抽獎(jiǎng)id

privateList<AwardPool> awardPools; //獎(jiǎng)池列表

//getter & setter

publicvoid setLotteryId(int lotteryId) {

if(id<=0){

thrownewIllegalArgumentException("非法的抽獎(jiǎng)id");

}

this.lotteryId = lotteryId;

}

//根據(jù)抽獎(jiǎng)入?yún)ontext選擇獎(jiǎng)池

publicAwardPool chooseAwardPool(DrawLotteryContext context) {

if(context.getMtCityInfo()!=null) {

return chooseAwardPoolByCityInfo(awardPools, context.getMtCityInfo());

} else{

return chooseAwardPoolByScore(awardPools, context.getGameScore());

}

}

//根據(jù)抽獎(jiǎng)所在城市選擇獎(jiǎng)池

privateAwardPool chooseAwardPoolByCityInfo(List<AwardPool> awardPools, MtCifyInfo cityInfo) {

for(AwardPool awardPool: awardPools) {

if(awardPool.matchedCity(cityInfo.getCityId())) {

return awardPool;

}

}

returnnull;

}

//根據(jù)抽獎(jiǎng)活動(dòng)得分選擇獎(jiǎng)池

privateAwardPool chooseAwardPoolByScore(List<AwardPool> awardPools, int gameScore) {...}

}

代碼演示3 DrawLottery

在匹配到一個(gè)具體的獎(jiǎng)池之后，需要確定最后給用戶的獎(jiǎng)品是什么。這部分的領(lǐng)域功能在AwardPool內(nèi)。

package com.company.team.bussiness.lottery.domain.valobj;

import...;

publicclassAwardPool{

privateString cityIds;//獎(jiǎng)池支持的城市

privateString scores;//獎(jiǎng)池支持的得分

privateint userGroupType;//獎(jiǎng)池匹配的用戶類型

privateList<Awrad> awards;//獎(jiǎng)池中包含的獎(jiǎng)品

//當(dāng)前獎(jiǎng)池是否與城市匹配

publicboolean matchedCity(int cityId) {...}

//當(dāng)前獎(jiǎng)池是否與用戶得分匹配

publicboolean matchedScore(int score) {...}

//根據(jù)概率選擇獎(jiǎng)池

publicAward 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;

}

}

returnnull;

}

}

代碼演示4 AwardPool

與以往的僅有g(shù)etter、setter的業(yè)務(wù)對(duì)象不同，領(lǐng)域?qū)ο缶哂辛诵袨?#xff0c;對(duì)象更加豐滿。同時(shí)，比起將這些邏輯寫在服務(wù)內(nèi)（例如**Service），領(lǐng)域功能的內(nèi)聚性更強(qiáng)，職責(zé)更加明確。

資源庫(kù)

領(lǐng)域?qū)ο笮枰Y源存儲(chǔ)，存儲(chǔ)的手段可以是多樣化的，常見的無非是數(shù)據(jù)庫(kù)，分布式緩存，本地緩存等。資源庫(kù)（Repository）的作用，就是對(duì)領(lǐng)域的存儲(chǔ)和訪問進(jìn)行統(tǒng)一管理的對(duì)象。在抽獎(jiǎng)平臺(tái)中，我們是通過如下的方式組織資源庫(kù)的。

//數(shù)據(jù)庫(kù)資源

import com.company.team.bussiness.lottery.repo.dao.AwardPoolDao;//數(shù)據(jù)庫(kù)訪問對(duì)象-獎(jiǎng)池

import com.company.team.bussiness.lottery.repo.dao.AwardDao;//數(shù)據(jù)庫(kù)訪問對(duì)象-獎(jiǎng)品

import com.company.team.bussiness.lottery.repo.dao.po.AwardPO;//數(shù)據(jù)庫(kù)持久化對(duì)象-獎(jiǎng)品

import com.company.team.bussiness.lottery.repo.dao.po.AwardPoolPO;//數(shù)據(jù)庫(kù)持久化對(duì)象-獎(jiǎng)池

import com.company.team.bussiness.lottery.repo.cache.DrawLotteryCacheAccessObj;//分布式緩存訪問對(duì)象-抽獎(jiǎng)緩存訪問

import com.company.team.bussiness.lottery.repo.repository.DrawLotteryRepository;//資源庫(kù)訪問對(duì)象-抽獎(jiǎng)資源庫(kù)

代碼演示5 Repository組織結(jié)構(gòu)

資源庫(kù)對(duì)外的整體訪問由Repository提供，它聚合了各個(gè)資源庫(kù)的數(shù)據(jù)信息，同時(shí)也承擔(dān)了資源存儲(chǔ)的邏輯（例如緩存更新機(jī)制等）。

在抽獎(jiǎng)資源庫(kù)中，我們屏蔽了對(duì)底層獎(jiǎng)池和獎(jiǎng)品的直接訪問，而是僅對(duì)抽獎(jiǎng)的聚合根進(jìn)行資源管理。代碼示例中展示了抽獎(jiǎng)資源獲取的方法（最常見的Cache Aside Pattern）。

比起以往將資源管理放在服務(wù)中的做法，由資源庫(kù)對(duì)資源進(jìn)行管理，職責(zé)更加明確，代碼的可讀性和可維護(hù)性也更強(qiáng)。

package com.company.team.bussiness.lottery.repo;

import...;

@Repository

publicclassDrawLotteryRepository{

@Autowired

privateAwardDao awardDao;

@Autowired

privateAwardPoolDao awardPoolDao;

@AutoWired

privateDrawLotteryCacheAccessObj drawLotteryCacheAccessObj;

publicDrawLottery getDrawLotteryById(int lotteryId) {

DrawLottery drawLottery = drawLotteryCacheAccessObj.get(lotteryId);

if(drawLottery!=null){

return drawLottery;

}

drawLottery = getDrawLotteyFromDB(lotteryId);

drawLotteryCacheAccessObj.add(lotteryId, drawLottery);

return drawLottery;

}

privateDrawLottery getDrawLotteryFromDB(int lotteryId) {...}

}

代碼演示6 DrawLotteryRepository

防腐層

亦稱適配層。在一個(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)中，我們定義了用戶城市信息防腐層(UserCityInfoFacade)，用于外部的用戶城市信息上下文（微服務(wù)架構(gòu)下表現(xiàn)為用戶城市信息服務(wù)）。

以用戶信息防腐層舉例，它以抽獎(jiǎng)?wù)埱髤?shù)(LotteryContext)為入?yún)?#xff0c;以城市信息（MtCityInfo）為輸出。

package com.company.team.bussiness.lottery.facade;

import...;

@Component

publicclassUserCityInfoFacade{

@Autowired

privateLbsService lbsService;//外部用戶城市信息RPC服務(wù)

publicMtCityInfo getMtCityInfo(LotteryContext context) {

LbsReq lbsReq = newLbsReq();

lbsReq.setLat(context.getLat());

lbsReq.setLng(context.getLng());

LbsResponse resp = lbsService.getLbsCityInfo(lbsReq);

return buildMtCifyInfo(resp);

}

privateMtCityInfo buildMtCityInfo(LbsResponse resp) {...}

}

代碼演示7 UserCityInfoFacade

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

上文中，我們將領(lǐng)域行為封裝到領(lǐng)域?qū)ο笾?#xff0c;將資源管理行為封裝到資源庫(kù)中，將外部上下文的交互行為封裝到防腐層中。此時(shí)，我們?cè)倩剡^頭來看領(lǐng)域服務(wù)時(shí)，能夠發(fā)現(xiàn)領(lǐng)域服務(wù)本身所承載的職責(zé)也就更加清晰了，即就是通過串聯(lián)領(lǐng)域?qū)ο蟆①Y源庫(kù)和防腐層等一系列領(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

publicclassLotteryServiceImplimplementsLotteryService{

@Autowired

privateDrawLotteryRepository drawLotteryRepo;

@Autowired

privateUserCityInfoFacadeUserCityInfoFacade;

@Autowired

privateAwardSendService awardSendService;

@Autowired

privateAwardCounterFacade awardCounterFacade;

@Override

publicIssueResponse 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í)體

}

privateIssueResponse buildIssueResponse(AwardSendResponse awardSendResponse) {...}

}

代碼演示8 LotteryService

數(shù)據(jù)流轉(zhuǎn)

數(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ū)ο?#xff08;DO）作為領(lǐng)域內(nèi)部的數(shù)據(jù)和行為載體；在資源庫(kù)內(nèi)部，我們沿襲了原有的數(shù)據(jù)庫(kù)持久化對(duì)象（PO）進(jìn)行數(shù)據(jù)庫(kù)資源的交互。同時(shí)，DTO與DO的轉(zhuǎn)換發(fā)生在領(lǐng)域服務(wù)內(nèi)，DO與PO的轉(zhuǎn)換發(fā)生在資源庫(kù)內(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)界面層功能。

DDD-分層

隨著業(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ù)。

DDD-系統(tǒng)架構(gòu)圖

注：具體的架構(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

publicclassLotteryApplicationService{

@Autowired

privateLotteryRiskService riskService;

@Autowired

privateLotteryConditionService conditionService;

@Autowired

privateLotteryService lotteryService;

//用戶參與抽獎(jiǎng)活動(dòng)

publicResponse<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)

}

}

privatevoid validateLoginInfo(LotteryContext lotteryContext){...}

privateResponse<PrizeInfo, ErrorData> buildErrorResponse (int code, String msg){...}

privateResponse<PrizeInfo, ErrorData> buildSuccessResponse (PrizeInfo prizeInfo){...}

}

代碼演示9 LotteryApplicationService

在本文中，我們采用了分治的思想，從抽象到具體闡述了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即可。

如果覺得本文對(duì)您有幫助，請(qǐng)點(diǎn)在看、分享朋友圈，感謝您的支持！

?-END-?

關(guān)注“技術(shù)領(lǐng)導(dǎo)力”公眾號(hào)

用故事講技術(shù)，有趣，有料！

想加入社區(qū)，跟100位互聯(lián)網(wǎng)大咖學(xué)習(xí)？

請(qǐng)?jiān)诠娞?hào)中回復(fù)：“加群”

---

大家在看：

1.罵戰(zhàn)之后，王垠加入華為，趙海平怒離職！

2.微信架構(gòu)總監(jiān)：10億日活場(chǎng)景下的微服務(wù)架構(gòu)

3.雷軍、張小龍：為何高手的努力深入而輕松

4.“阿里技術(shù)Leader拿那么多錢，每天都干些啥？

5.馬化騰和張一鳴的灰度思維是什么？

6.我是如何在獨(dú)角獸公司做業(yè)務(wù)中臺(tái)、數(shù)據(jù)中臺(tái)?

喜歡就點(diǎn)在看！

總結(jié)

以上是生活随笔為你收集整理的美团点评DDD在微服务架构中的实践！10张ppt一次讲透的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。