[[398256]]

 本文轉(zhuǎn)載自微信公眾號「Java藝術(shù)」，作者wujiuye。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號。

DDD為什么難推行?因為我們習(xí)慣了舒適，并不是我們不想接受新事物，而是因為我們懶思考，習(xí)慣了以往一貫的流程開發(fā)、面向數(shù)據(jù)庫CRUD開發(fā)，很難轉(zhuǎn)換思維。

DDD要求我們根據(jù)產(chǎn)品原型建模，識別領(lǐng)域、限界上下文、子域，這些需要時間思考的問題就像一座座大山，讓我們望而卻步。且由于項目前期看不到DDD帶來的高效，反而沒那么敏捷了，并且前期的建模還可能要推倒重來，這讓更多人一開始就想放棄，而只有隨著需求的不斷迭代，DDD才會顯示出它的優(yōu)勢。

本篇筆者就以近期的一個項目跟大家分享筆者為該項目識別領(lǐng)域、限界上下文、子域，以及建模的過程。當(dāng)然，分享的只是最初的一個版本。

領(lǐng)域通常指的就是業(yè)務(wù)范圍，每個公司都有自己明確的業(yè)務(wù)范圍。通常每個公司內(nèi)部都有很多個系統(tǒng)，如一家電商公司可能會有物流系統(tǒng)、電商系統(tǒng)、直播系統(tǒng)等等，每個系統(tǒng)做的事情則是更細(xì)分的領(lǐng)域。

茉莉紅交所項目是筆者入職茉莉數(shù)科集團后做的第一個項目，也是一個新的項目，由于沒有太多歷史包袱，筆者選擇從零開始搭建整個項目。并且由于初期業(yè)務(wù)簡單，所以才選擇在該項目試行DDD，寄希望于隨著業(yè)務(wù)的不斷迭代，能夠看到DDD發(fā)揮出的優(yōu)勢。

最初從產(chǎn)品那里了解到該項目要做的業(yè)務(wù)就是OTO(線上到線下)探店，那么OTO探店就是我們要了解的領(lǐng)域。

探店其實是達(dá)人幫助商家做推廣的一種有償活動，商家通過免費讓達(dá)人品嘗美食或是免門票游玩景點，達(dá)人最終通過短視頻、直播、圖文內(nèi)容等方式為商家做推廣。無論是探美食店、探游樂園，探店都是這個領(lǐng)域的核心。

在探店這個領(lǐng)域中，核心的業(yè)務(wù)名詞有：商家、達(dá)人、店鋪、訂單、任務(wù)。而行為有：商家發(fā)布探店訂單，訂單關(guān)聯(lián)店鋪，商家認(rèn)證店鋪，達(dá)人接單(任務(wù))，商家發(fā)布訂單時通知達(dá)人，達(dá)人完成任務(wù)時通知商家。

現(xiàn)在，我們需要為業(yè)務(wù)劃分限界上下文。

限界上下文是業(yè)務(wù)概念的邊界，是業(yè)務(wù)問題最小粒度的劃分。在OTO探店業(yè)務(wù)領(lǐng)域中會包含多個限界上下文，我們通過找出這些確定的限界上下文對系統(tǒng)進(jìn)行解耦，要求每一個限界上下文其內(nèi)部必須是緊密組織的、職責(zé)明確的、具有較高的內(nèi)聚性。

我們劃分出的限界上下文如下圖所示。

為什么將任務(wù)和訂單拆分為不同限界上下文(任務(wù)不是作為訂單聚合根的實體，而是作為一個獨立聚合的聚合根)?這是因為商家發(fā)布的一個訂單允許有不同的多個達(dá)人接單，一個達(dá)人也可以接不同商家的訂單，這并不是簡單的一對多關(guān)系。這更像是商品與訂單的關(guān)系，而不是訂單與訂單item的關(guān)系。

在劃分出限界上下文后，還需要根據(jù)限界上下文識別出問題子域。問題子域是對業(yè)務(wù)問題的劃分，相對限界上下文來說，是對業(yè)務(wù)問題更大粒度的劃分。

• 核心(子)域：產(chǎn)品的核心競爭力、盈利來源;
• 通用子域：常見的，不同領(lǐng)域都可共用的，可通過購買就能使用的;
• 支撐子域：非核心域、又非通用域，具有個性化需求，用于支撐核心域運作;

根據(jù)限界上下文，我們劃分出的子域如下圖所示。

OTO探店核心域：商家創(chuàng)建訂單、平臺對訂單審核，達(dá)人接單后生成任務(wù)、平臺對任務(wù)審核，達(dá)人完成任務(wù)回填內(nèi)容鏈接;

商家支撐子域：商家注冊、商家審核;

達(dá)人支撐子域：達(dá)人注冊、達(dá)人檔案管理、達(dá)人粉絲數(shù)據(jù)提取;

店鋪支撐子域：商家注冊店鋪、店鋪審核;(根據(jù)下版本的需求，將把店鋪當(dāng)作商家聚合根的實體)

消息通知通用子域：短信通知、應(yīng)用內(nèi)通知、小程序消息推送。

在劃分出子域后，我們就可以為領(lǐng)域建模了。

領(lǐng)域建模是通過將業(yè)務(wù)抽象為聚合、實體、聚合根、值對象模型的方式，封裝和承載全部的業(yè)務(wù)邏輯，保持業(yè)務(wù)的高內(nèi)聚和低耦合。

聚合：負(fù)責(zé)封裝業(yè)務(wù)邏輯，內(nèi)聚決策命令和領(lǐng)域事件，容納實體、聚合根、值對象。

• 聚合根：也是一種實體，是聚合的根節(jié)點，如訂單;
• 實體：聚合的主干，具有唯一標(biāo)識和生命周期，如訂單Item;
• 值對象：實體的附加業(yè)務(wù)概念，用于描述實體所包含的業(yè)務(wù)信息，如訂單收件地址。

在技術(shù)實現(xiàn)上，一個聚合就是一個包，里面存放領(lǐng)域服務(wù)、工廠、資源庫、聚合根、實體、值對象。

領(lǐng)域?qū)影膭澐忠?guī)則通常為：

--domain 
----限界上下文 
------聚合 
-------- （聚合根、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件） 
------聚合 
-------- （聚合根、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件） 

特別的，一個限界上下文可能包含多個聚合，但一個聚合只能存在于一個限界上下文。 如果一個限界上下文只有一個聚合，這種情況下我們通常省略限界上下文這一層。

以訂單限界上下文、任務(wù)限界上下文為例：

--domain 
----ordercontext 
------orderType(訂單類型聚合（特殊的聚合，用于管理訂單分類）：美食（早餐/午餐/晚餐/下午茶）、...) 
------order 
----task 

由于訂單存在兩個聚合，因此我們沒有省略訂單限界上下文這一層，而任務(wù)只有任務(wù)聚合，所以省略了任務(wù)限界上下文這一層。

以上包的劃分只是領(lǐng)域?qū)拥膭澐?，要求聚合根、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件等類存放在聚合包下，無論是使用DDD經(jīng)典四層架構(gòu)，還是六邊形架構(gòu)。

我們并非采用DDD經(jīng)典四層架構(gòu)，也非六邊形架構(gòu)，我們實際對項目包的劃分如下。

當(dāng)我們需要按限界上下文拆分訂單和任務(wù)為兩個微服務(wù)時，只需要copy一份項目代碼，一個項目中去掉ordercontext包，一個項目中去掉task包，并且將兩個限界上下文應(yīng)用層之間的依賴調(diào)用改為通過遠(yuǎn)程RPC調(diào)用。上圖中的xxxGateway類就是用于封裝遠(yuǎn)程調(diào)用的，UserApplicationServiceGateway、RabbitmqConfiguration之所以放在最外層，因為兩個限界上下文都會用到。

以任務(wù)聚合為例，展開后的包結(jié)構(gòu)如下。

以上全部就是我們最初對OTO探店業(yè)務(wù)識別限界上下文、拆分子域、領(lǐng)域建模的過程，根據(jù)目前需求排期來看，這個模型我們即將要推倒重來一次，但對代碼的改動應(yīng)該不大。

因為DDD缺少權(quán)威性的實踐指導(dǎo)和代碼約束，我們只能是通過實踐慢慢積累經(jīng)驗。