[[398256]]

 本文轉載自微信公眾號「Java藝術」，作者wujiuye。轉載本文請聯系Java藝術公眾號。

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

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

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

領域通常指的就是業務范圍，每個公司都有自己明確的業務范圍。通常每個公司內部都有很多個系統，如一家電商公司可能會有物流系統、電商系統、直播系統等等，每個系統做的事情則是更細分的領域。

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

最初從產品那里了解到該項目要做的業務就是OTO(線上到線下)探店，那么OTO探店就是我們要了解的領域。

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

在探店這個領域中，核心的業務名詞有：商家、達人、店鋪、訂單、任務。而行為有：商家發布探店訂單，訂單關聯店鋪，商家認證店鋪，達人接單(任務)，商家發布訂單時通知達人，達人完成任務時通知商家。

現在，我們需要為業務劃分限界上下文。

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

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

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

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

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

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

OTO探店核心域：商家創建訂單、平臺對訂單審核，達人接單后生成任務、平臺對任務審核，達人完成任務回填內容鏈接;

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

達人支撐子域：達人注冊、達人檔案管理、達人粉絲數據提取;

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

消息通知通用子域：短信通知、應用內通知、小程序消息推送。

在劃分出子域后，我們就可以為領域建模了。

領域建模是通過將業務抽象為聚合、實體、聚合根、值對象模型的方式，封裝和承載全部的業務邏輯，保持業務的高內聚和低耦合。

聚合：負責封裝業務邏輯，內聚決策命令和領域事件，容納實體、聚合根、值對象。

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

在技術實現上，一個聚合就是一個包，里面存放領域服務、工廠、資源庫、聚合根、實體、值對象。

領域層包的劃分規則通常為：

--domain 
----限界上下文 
------聚合 
-------- （聚合根、值對象、實體、領域服務、資源庫、領域事件） 
------聚合 
-------- （聚合根、值對象、實體、領域服務、資源庫、領域事件） 

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

以訂單限界上下文、任務限界上下文為例：

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

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

以上包的劃分只是領域層的劃分，要求聚合根、值對象、實體、領域服務、資源庫、領域事件等類存放在聚合包下，無論是使用DDD經典四層架構，還是六邊形架構。

我們并非采用DDD經典四層架構，也非六邊形架構，我們實際對項目包的劃分如下。

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

以任務聚合為例，展開后的包結構如下。

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

因為DDD缺少權威性的實踐指導和代碼約束，我們只能是通過實踐慢慢積累經驗。