說說我個人的理解：四色造型是用來做什么的？在“系統(tǒng)分析”階段，四色原型法并不要求建模前一定有需求。您在熟悉和了解業(yè)務的過程中可以直接使用四色原型分析。并表達業(yè)務，在任何理解業(yè)務的過程中都可以用它來抽象和組織業(yè)務概念。四色原型是一種思維工具，可以讓系統(tǒng)分析師戴上有色眼鏡看世界。通過將分析對象分為四大類，可以快速發(fā)現(xiàn)隱藏的概念和獨立的職責，將模型對象變成概念上具有凝聚力、單一職責的對象，是系統(tǒng)分析過程中最有意義的思維工具。今天給大家分享一篇關于DDD領域建模的實用文章。它是根據(jù)我個人近三年來的DDD實踐經(jīng)驗，基于企業(yè)級電商項目的DDD領域設計的。希望能給大家一些DDD方面的啟發(fā)。我將從DDD領域分析、DDD設計呈現(xiàn)、領域建模實際案例開始講解。稍后還有彩蛋給大家哦~話不多說，開始DDD之旅吧~

0x1

DDD領域分析在講DDD之前，我們需要先了解一些基本概念。大家都知道DDD指的是領域驅動設計，那么我們如何理解DDD呢？ DDD就是事件風暴（分類劃分），然后知道組織劃分（中臺）、系統(tǒng)劃分（微服務）、代碼劃分/設計的思維方法。這種理解可能比較抽象，但實際上其本質是通過將復雜的問題簡單化、分解、克服來降低復雜性。 DDD的出現(xiàn)，符合當今流行的微服務架構。微服務架構有一個特別重要的命題——：如何合理劃分微服務，而DDD的策略設計可以作為微服務劃分的基礎。當我們談論DDD時，它實際上包括戰(zhàn)略設計和戰(zhàn)術設計。那么它們之間有什么區(qū)別呢？

戰(zhàn)略設計：業(yè)務層面的領域建模，強調業(yè)務領域模型的識別和邊界劃分。簡單來說就是業(yè)務設計，與代碼呈現(xiàn)無關；戰(zhàn)術設計：工程層面的架構設計和模型設計，具體應用于微服務即完成微服務設計。兩者哪個更重要？我認為戰(zhàn)略設計比戰(zhàn)術設計更重要。在實際生產(chǎn)中，業(yè)務會越來越復雜，代碼也會越來越大。如果業(yè)務不劃分，表設計不劃分和設計，最后系統(tǒng)就會變成一個巨大的單體應用，疊加需求修改代碼。一旦發(fā)生，一根頭發(fā)就會牽動全身。如果通過戰(zhàn)略設計對業(yè)務進行合理劃分，各個業(yè)務的業(yè)務邊界就會特別清晰。即使我們的代碼沒有使用DDD思想來完成構建，即使我們仍然使用傳統(tǒng)的MVC架構，也不會影響業(yè)務的正常運行。戰(zhàn)略設計是產(chǎn)品需求和開發(fā)代碼之間的橋梁。領域驅動的戰(zhàn)略設計應該如何分析？我們不需要單獨探索，我們可以總結前人的一些經(jīng)驗：

通用語言：它的作用是定義上下文含義，以便有界上下文定義域邊界。事件風暴：由許多人參與，包括項目團隊和領域專家，頭腦風暴用于分析用戶故事并找到并建立領域對象的四色構造。模型：按照時間發(fā)展的順序，標識“溯源文件”作用的“時間尺度”概念直達核心業(yè)務數(shù)據(jù)；它強調可追溯性和執(zhí)行效率之間的界限。紙筆建模：回到一百年前，在我們一個沒有電腦的時代，我們會用什么方法來做商業(yè)設計？我們可以用紙筆畫表寫例子，管理核心領域的“剛好夠用”的數(shù)據(jù)，增強數(shù)據(jù)完整性，避免過度設計DCI建模：也許我們對DCI的了解較少，但事實上， DCI架構和MVC架構是同一個人。 DCI建模通過角色扮演模型讓領域模型變得簡單易懂，通過小類和大對象避免出現(xiàn)上帝般的問題；同時還可以解決貧血模型和擁塞模型之間的爭議，使模塊更具內聚性和低耦合性；當然，DCI建模也可以與四色建模結合使用。那么，領域驅動的戰(zhàn)術設計應該如何實施呢？在我看來，只考慮兩個大方向：

模型設計：例如是否使用擁塞模型或貧血模型。架構設計：比如DDD/CQRS、干凈架構、六邊形架構、清晰架構、DCI架構……至此，我們對DDD的一些基本概念有了清晰的認識，那么為什么DDD對我們如此重要呢？我相信DDD可以指導我們的業(yè)務設計和代碼實現(xiàn)，讓維護變得更加簡單。 DDD 指導設計：

從業(yè)務領域角度劃分領域邊界，構建高效溝通的通用語言，降低新團隊成員熟悉業(yè)務的成本。在持續(xù)溝通的過程中，通過提煉領域概念和業(yè)務抽象來建立領域模型，以保持業(yè)務和代碼的邏輯一致性。通過領域模型的分類和行為分析，保證業(yè)務實現(xiàn)的準確性。領域建模比數(shù)據(jù)庫建模更輕量、更全面，而數(shù)據(jù)庫建模不能完全反映系統(tǒng)的所有特性和需求。 DDD 指導實施：

在不過多依賴系統(tǒng)設計者的經(jīng)驗和背景的情況下，指導表設計和代碼實現(xiàn)指導微服務的設計和拆分。 —— 劃定了清晰的微服務邊界，并允許輕松維護可持續(xù)發(fā)展的微服務架構：

從討論、設計到評審和實現(xiàn)，都是使用領域模型進行溝通，領域模型可以作為系統(tǒng)業(yè)務的核心載體，在微服務的維度上劃分有界上下文。服務拆分只需要去掉對應的有界上下文即可減少業(yè)務需求。迭代帶來的維護成本（比如模型變更）這就是DDD對我們的重要性。我們不能只用發(fā)展的眼光來看待業(yè)務問題，否則就會陷入發(fā)展思維的陷阱，無助于我們業(yè)務的成長。接下來我們回顧一下DDD ——的核心要素有哪些

領域是指在特定范圍或邊界內要解決的業(yè)務問題域。其核心思想是將業(yè)務問題域細分為子域/核心域/通用域/支持域，以降低業(yè)務理解和系統(tǒng)實現(xiàn)的復雜度。聚合（Aggregate） 聚合包括聚合根、實體和值對象。 DDD 中的聚合并不等同于UML 中的聚合。我們使用擁塞模型來設計領域模型的屬性和行為，并識別聚合和聚合根。值得注意的是，微服務至少應該不小于聚合，以避免引入分布式事務的復雜性。有界上下文（BC）業(yè)務的通用語言有其業(yè)務邊界。我們不可能用一個簡單的術語來毫無歧義地描述一個復雜的業(yè)務領域。 BC用于細分領域，從而定義共同的語言邊界。 BC包含一個或多個聚合，根據(jù)業(yè)務領域概念劃分為不同的BC。對應的Java代碼級別是頂層包目錄結構。 BC內部高內聚，一個業(yè)務行為應該盡可能使用BC內部的線程級交互，以保證ACID； BC之間耦合度低，可以作為微服務設計和拆分的基礎。當然，微服務拆分的粒度也需要結合企業(yè)運維能力。 BC之間最好使用領域事件進行交互，或者引入一個“翻譯器”（或防腐層）進行通信，以保持BC之間的松耦合。 DDD的核心要素就只有這三個。如果我們了解了這三個要素，我們就可以開始做很多事情。當然，我們還需要了解領域建模的一些難點，比如：

領域發(fā)現(xiàn)：難點在于領域模型的概念提煉、模型分析和分類；領域劃分：難點在于如何清晰劃分業(yè)務邊界和應用邊界，如何控制業(yè)務設計的粒度，是自下而上歸納劃分還是自上而下歸納劃分。演繹除法；領域建模：難點在于如何識別聚合、聚合根、實體、值對象，如何建立領域模型之間的關系和核心交互等。

0x2

DDD設計演示——四色造型

當我們收到需求時，我們會在腦海中過一遍實現(xiàn)代碼。這對于簡單的CRUD來說并不困難，但是當涉及到更復雜的業(yè)務時，一個場景我們就需要很長時間才能溝通清楚。我們應該做什么？呢絨？其實很簡單。我們需要一個載體來沉淀思維過程。當產(chǎn)品經(jīng)理來找我們增加需求評估的范圍時，當新員工入職并向他解釋業(yè)務時，這個載體都可以直觀地呈現(xiàn)出來。這就是DDD設計呈現(xiàn)的魅力。這里我使用我個人比較容易使用的四色建模方法作為DDD的設計呈現(xiàn)。四色建模方法是一種領域模型的分析方法。重點是領域模型的分類。它是一種呈現(xiàn)方法。四色原型誕生于20世紀90年代。它首先由Peter Coad 和Mark Mayfield [Coad92] 提出，然后由David North [Coad95-97] 擴展。它是一種廣泛使用的系統(tǒng)分析方法。使用四色建模方法設計的四色圖表達了類圖，該類圖是包括序列圖的完全動態(tài)圖。它是三維的、多維的，與完全靜態(tài)的數(shù)據(jù)庫ER圖不同。那么四色原型機具體有哪四種顏色呢？我們看一下：時刻間隔原型（MI）表示在某一時刻或某段時間內發(fā)生的事情，例如銷售訂單、客戶賬單、付款記錄等，用淺紅色表示。 PPT原型（Part-Place-Thing Archetype，People/Thing/Thing Archetype，簡稱PPT）代表扮演不同角色的人或物，如產(chǎn)品、賬戶、商店等，用淺綠色表示。角色原型（簡稱ROLE）抽象出一種參與方式，由人或組織、場所或物品承擔，如客戶、商家、倉儲團隊、金融組織等，用淺黃色表示。描述Archetype（簡稱DESC）是一種數(shù)據(jù)類型的資源，目錄類型對象，或者可以被其他原型重復使用，例如產(chǎn)品類別、支付方式、方法值對象等，用淺藍色表示。接下來我們使用四色建模方法來分析領域模型，分為四大步驟：

建立時間尺度原型：尋找需要追蹤的事件，并根據(jù)追蹤的事件找到足跡。建立PPT原型：豐富模型，圍繞時間尺度原型尋找人/事/物，使其能夠更好地描述業(yè)務理念。建立角色原型：進一步學習。抽象出可以參與不同流程的角色，建立描述原型：用描述對象補充一些信息。這里需要注意的是，整個過程中會穿插一些原型之間的關系/核心交互的注釋。我們來看一個電商DDD的四色圖示例：

0x3

領域建模的實際案例如下圖所示。這是金融領域模型和支付中心模型的一部分。只描述了業(yè)務系統(tǒng)如何運行，不涉及表的具體字段設計。完整模型圖涉及敏感信息，不詳細展示：

領域建模就是這樣一種建模。這里我提一下一些設計細節(jié)：

粉色指的是時間尺度原型，是核心業(yè)務產(chǎn)生的數(shù)據(jù)?；旧希瑢谋碓O計模型屬性不需要體現(xiàn)表的審計字段，比如通用ID、創(chuàng)建者、修改時間、軟刪除標識等，模型行為也只需要設計核心行為即可。不需要寫出常規(guī)的CRUD方法。設計必須知道如何在BC內選擇模型。除了依賴關系、聚合等之外，還可以使用箭頭來連接跨BC 的模型之間的核心交互。它們之間的模型通過虛線箭頭連接。這里我結合DCI建模方法（D代表數(shù)據(jù)，C代表上下文和場景，I代表模型之間的交互）。針對業(yè)務的獨特屬性，我采用加粗的方式展示。您不再需要費心與其他人一起分析用于構建這些模型的維度。對于尚未上線的屬性變更（新增/修改），使用紅色標記，因為領域模型圖是有界上下文的劃分，指導我們的業(yè)務發(fā)展。這是一個非常主觀的邊界劃分。為了后續(xù)代碼的靈活調整，不需要在Controller的URL設計中添加有界上下文域模型圖。就像代碼一樣，它需要我們長期維護。并不意味著設計完成后就不會完成。去吧，照顧好它。這個非常重要。微服務負責人必須有這個意識。