[[398256]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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