大家好，歡迎來到Tlog4J課堂，我是Jensen。

今天給大家分享一篇DDD領域建模實戰，結合我個人三年來的DDD實踐經驗，以企業級電商項目DDD領域設計為出發點，希望能給到大家對DDD的一些啟發。

我會從DDD領域分析、DDD設計呈現、領域建模實際案例來展開說明，后面會有彩蛋給到大家~

話不多說，咱們開始DDD之旅吧~

DDD領域分析

講DDD之前，咱們得了解一些基本概念，大家都知道DDD指的是領域驅動設計(Domain-Driven Design)，那怎么理解DDD呢?

DDD是一個事件風暴(分類劃分)，進而知道組織劃分(中臺)、系統劃分(微服務)、代碼劃分/設計的思想方法。

這么理解可能比較抽象，其實它的本質就是：通過將復雜問題簡單化，分而治之，降低復雜度。

DDD的出現，契合了當今流行的微服務架構，微服務架構有個特別重要的命題——如何合理劃分微服務，而DDD的戰略設計完全可以作為微服務劃分的依據。

我們講DDD，它其實是包括了戰略設計和戰術設計，那他倆有啥區別呢?

• 戰略設計：業務層面的領域建模，它強調業務領域模型的識別與邊界劃分，簡單來說就是業務設計，與代碼呈現無關。
• 戰術設計：工程層面的架構設計與模型設計，具體應用到微服務就是完成微服務設計。

這兩者誰更重要呢?我認為，戰略設計比戰術設計更加重要。

在實際生產中，業務會越來越復雜，代碼也會越壘越龐大，如果業務沒有經過劃分，表設計也沒有經過劃分設計，最后系統將變成一個龐大的單體應用，疊加需求修改代碼的時候將會牽一發而動全身。

如果業務經過戰略設計合理去劃分，每個業務的業務邊界會顯得特別清晰，即使我們的代碼沒有使用DDD的思想去完成搭建，即使我們還是使用傳統的MVC架構，也不會影響業務正常運作，戰略設計是連接產品需求與開發代碼的一道橋梁。

那領域驅動的戰略設計應該如何分析呢?我們不需要獨自去摸索，總結前輩的一些經驗即可：

• 通用語言：它的作用是定義上下文含義，以便限界上下文定義領域邊界。
• 事件風暴：由項目團隊、領域專家等多人參與，采用頭腦風暴的方式進行用戶故事分析，找出并建立領域對象。
• 四色建模：按時間發展先后順序，識別“追溯單據”作用的“時標”概念，直達業務核心數據;它強調可追溯性與執行效率。
• 限界紙筆建模：回到一百年前，在一個我們沒有計算機的年代，我們要做業務設計會用什么方法呢?我們可以用紙和筆畫表格并寫實例，管理核心領域“恰好夠用”的數據，增強數據完整性，避免過度設計。
• DCI建模：可能DCI我們聽得比較少，其實DCI架構與MVC架構的提出者是同一個人。DCI建模通過角色扮演模型使得領域模型易于理解，通過小類大對象的手法避免上帝類的問題;同時它也能解決貧血模型和充血模型之爭，使模塊更加高內聚、低耦合;當然，DCI建模也可以與四色建模融合使用。

那么，領域驅動戰術設計應該如何落地呢?我認為，考慮兩個大方向即可：

• 模型設計：比如，使用充血模型還是貧血模型。
• 架構設計：比如，DDD/CQRS、整潔架構、六邊形架構、清晰架構、DCI架構……

至此，我們了解清楚了DDD的一些基本概念，那DDD為什么對我們如此重要呢?

我認為，DDD可以指導我們業務設計，指導我們代碼落地，使得維護變得更簡單。

DDD指導設計：

• 從業務領域視角劃分領域邊界，構建通用語言進行高效溝通，降低團隊新成員對業務的熟悉成本。
• 在不斷交流的過程中，通過提煉領域概念與業務抽象建立領域模型，維持業務和代碼的邏輯一致性。
• 通過對領域模型歸類與行為分析，保證實現業務的準確性。
• 領域建模比數據庫建模更輕更全面，而數據庫建模不能完全反映系統的全部特性和需求。

DDD指導落地：

• 不過分依賴系統設計人員的經驗背景，指導表設計、代碼落地。
• 指導微服務的設計和拆分——劃分出清晰的微服務邊界、可持續演進的微服務架構。

簡易維護：

• 從討論、設計，到評審、落地，以領域模型進行交流，可作為系統業務的核心載體。
• 以微服務的維度劃分限界上下文，服務拆分只需要把相應的限界上下文拆出去即可。
• 減少因業務需求迭代(如：模型變更)帶來的維護成本。

這就是DDD對我們的重要意義，我們不能只以開發視角去看待業務問題，那樣的話就會陷入開發思維陷阱，這對我們的業務成長沒有任何幫助。

接下來，咱們來回顧一下，DDD有哪些核心要素——

領域(Domain)

領域是指在特定的范圍或邊界內要解決的業務問題域，它的核心思想是將業務問題域逐級細為子域/核心域/通用域/支撐域，降低業務理解和系統實現的復雜度。

聚合(Aggregate)

聚合內包括聚合根、實體、值對象，DDD中的聚合是不等同于UML中的聚合的，我們使用充血模型設計領域模型的屬性、行為，并識別聚合與聚合根。

值得注意的是，一個微服務最小不要小于一個聚合，避免引入分布式事務的復雜度。

限界上下文(Bounded Context，簡稱BC)

業務的通用語言有它的業務邊界，我們不大可能用一個簡單的術語沒有歧義地去描述一個復雜的業務領域，BC就是用來細分領域，從而定義通用語言所在的邊界。

BC包含一個或多個聚合，按業務領域概念劃分到不同BC，對應Java代碼層面就是頂層包目錄結構。

BC之內高內聚，一個業務行為在BC內盡量使用線程級別的交互，以保證ACID;BC之間低耦合，可作為微服務設計和拆分的依據，當然，微服務的拆分粒度還需要結合企業運維的能力。

BC之間最好采用領域事件進行交互，或者引入“翻譯器”(或者說防腐層)進行通訊，保持BC間的松耦合。

DDD的核心要素就這三個，搞懂這三個要素，咱們就可以開始搞很多事情了。

當然，領域建模的一些難點咱們也要有所了解，比如：

• 領域發現：難點在于領域模型的概念提煉、模型分析與歸類;
• 領域劃分：難點在于業務邊界和應用邊界如何清晰劃分，如何把控業務設計的粒度，是自底向上歸納劃分還是自頂向下演繹劃分;
• 領域建模：難點在于如何識別聚合、聚合根、實體、值對象，如何確立領域模型之間的關系與核心交互等等。

DDD設計呈現之——四色建模

在我們接到需求的時候，會在腦子里把實現的代碼過一遍，這對于簡單的CRUD來說并不難，但是涉及到更復雜的業務，一個場景就夠我們溝通很久才能說清楚，那怎么辦呢?

其實很簡單，我們需要一個載體，去把思考的過程沉淀下來，等到產品經理來找我們加需求評估影響范圍的時候，新人入職給他講解業務的時候，通過這個載體就能直觀地呈現出來，這就是DDD設計呈現的魅力所在。

這里我以我個人用得比較順手的四色建模法作為DDD的設計呈現。

四色建模法是對領域模型的一種分析方法論，關注點是領域模型的歸類，它是一種呈現方法。

四色原型延生于90年代，最先由Peter Coad和Mark Mayfield提出[Coad92]，然后由David North拓展[Coad95-97]，是一種被廣泛使用的系統分析方法。

使用四色建模法設計出來的四色圖，它所表達的類圖是一種包含順序圖的完全動態圖，它是立體多維的，有異于完全靜態的數據庫ER圖。

那四色原型具體是哪四色呢?我們一起來看看：

時標原型(Moment-Interval Archetype，簡稱MI)

表示事物在某個時刻或某一段時間內發生的，如銷售訂單、客戶賬單、收款記錄等，使用淺紅色表示。

PPT原型(Part-Place-Thing Archetype，人/事/物原型，簡稱PPT)

表示參與扮演不同角色的人或事物，如商品、賬戶、店鋪等，使用淺綠色表示。

角色原型(Role Archetype，簡稱ROLE)

抽象了一種參與方式，由人或組織機構、地點或物品來承擔，如客戶、商家、倉儲團隊、財務組織等，使用淺黃色表示。

描述原型(Description Archetype，簡稱DESC)

屬于資料類型的資源、目錄式的種類性質對象，或者可以被其他原型反復使用的，如商品類目、支付方式、方法值對象等，使用淺藍色表示。

接下來，咱們使用四色建模法來分析領域模型，總共分為四大步：

1. 建立時標原型：尋找需要追溯的事件，根據追溯事件尋找足跡。
2. 建立PPT原型：豐富模型，尋找時標原型周圍的人/事/物，使它可以更好地描述業務概念。
3. 建立角色原型：進一步從中抽象出可以參與到不同流程中去的角色。
4. 建立描述原型：把一些信息用描述對象補足。

這里咱們需要注意的是，整個過程會穿插著原型之間關系/核心交互的標注，我們來看一幅電商DDD的四色圖案例：

領域建模實際案例

如下圖所示，這是財務領域模型和支付中心模型的一部分，這里只描述了業務系統是如何運作起來的，并沒有涉及表的具體字段設計，全量的模型圖因涉及敏感信息不作詳細展示：

領域建模就是這么個建模，這里我提一些設計細節：

• 粉紅色指的是時標原型，是核心業務產生的數據，基本上對應表設計。
• 模型屬性不需要體現表的審計字段，比如通用的ID、創建者、修改時間、軟刪除標識等，模型行為也只需要設計核心行為即可，那種約定俗成的CRUD方法就不需要寫出來了，設計要懂得取舍。
• BC內模型除了依賴、聚合等等連線，可使用箭頭連接模型之間的核心交互，跨BC之間的模型使用虛線箭頭連接，這里我是結合了DCI建模法(D表示數據，C表示上下文、場景，I表示模型間的交互)。
• 對于表示業務唯一的屬性，我使用了加粗展示，再也不用跟別人費勁去解析這些模型是用什么維度去建的了
• 對于還沒上線的屬性變動(新增/修改)，使用紅色標記，因為領域模型圖是指導我們業務開發的。
• 限界上下文的劃分是一種非常主觀的邊界劃分，為了后續代碼能夠靈活調整，在Controller的URL設計里不需要加上限界上下文。

領域模型圖就像代碼一樣，需要我們長期去維護的，不是說做完設計就不去管了，這一點很重要，微服務負責人一定要有這個意識。

關于DCI建模和DCI架構我會繼續深入研究，DCI這塊就留到下次再分享叭~

彩蛋!

分享一個Pro****On在線畫圖平臺永久白嫖使用的方法：

1. 首先買個一年的Pro****On個人會員(159元/年)。
2. 建一個備用的文件夾，里面放各種類型的圖。
3. 等到會員過期后，你還需要建新圖的話，就從備用文件夾里移出來修改使用即可。

我個人一直都在使用Pro****On在線畫圖平臺，因為它可以畫腦圖和各種UML圖，支持在線協作，也支持在線圖片嵌入站外(如WIKI)。

當然，它還是一個學習設計的比較開放的平臺，你可以去它的海量模板庫克隆別人的圖，看看別人是怎么做軟件設計的，你也可以把自己畫得賊6的圖付費發布出去，體驗一下知識變現的樂趣，記得要脫敏哦~

好了，這次的DDD領域建模實戰課就到這里，你學會(fei)了嗎?