如何使用DDD分析一個項目
1. DDD簡介
DDD及Domain Drive Design（領域驅動設計），它力求將一個複雜的大型項目拆分成若干個內容相對獨立的小項目，以降低開發難度，加速開發速度，最終可以按照業務領域將一個Allinone的大型系統拆解爲一個分佈式的系統。
DDD自上而下可以分爲領域、界限上下文、領域服務、聚合根、聚合、實體、值對象。
- 領域：領域是DDD中最大的概念，領域是確定業務邊界的技術體現，系統開發時最終會映射爲業務羣或獨立服務，領域按照業務需求又可分爲核心域（業務核心邏輯）、通用域（可複用公共能力）、支撐域（繼承支撐能力）。
- 界限上下文：主要用來確定業務領域邊界，界限上下文應由領域專家或架構師跟進行業經驗來確定，界限上下文決定了領域的高內聚劃分和最終架構設計方案，反過來，領域劃分的是否合理也衡量了界限上下文的合理性。
- 領域服務：爲上層建築提供本領域對象的操作接口，負責對領域對象進行調度和封裝，到這裏，領域服務已經可以映射爲一個微服務了，一個領域可以包含若干個領域服務，同樣一個領域服務也可以包含若干個領域。
- 聚合根：聚合根是一個領域中最主要的領域對象，聚合根可以關聯領域中的所有聚合、實體和值對象，在數據建模時聚合根可以映射爲一張數據表。
- 聚合：一個聚合根中可以包含若干個聚合，每個聚合可以看作領域中的一個子領域。
- 實體：是最小的領域對象，它已經是一張不可再分割的數據表了。
- 值對象：是實體中相對不變的屬性的集合，只有數據初始化操作和極少數的修改操作會變更它，它的變更不應包含任何業務的邏輯，如用戶表中的暱稱、性別等。
按照以上拆解步驟，DDD建模分析有一套相對固定的分析過程，總結爲三板斧：
- 領域建模
- 領域和聚合根劃分
- 聚合、實體和值對象劃分
2. DDD建模三板斧
下面用一個例子來解釋三板斧怎麼進行DDD建模：
舉一個非常老套的例子，一句話需求：我要建一個B2C的電商平臺。
-
第一板斧：領域建模
第一步：明確需求，通過和產品經理扯皮得出，我要建一個電商平臺，我可以往裏面添加商品，用戶可以購買我的商品。到這裏電商平臺的大基調基本確定，這個平臺得有用戶、商品、訂單。
第二部：集中討論，也就是所謂的事件風暴，一個大白牆，幾個馬克筆，一沓貼紙，大家暢所欲言，就如下圖所示。
![]()
事件風暴的大體思路是：先將需求分解爲一個一個的動作（這個動作就是領域事件），再根據動作分析動作的作用對象，形成一個領域對象和領域事件的關係聚合。
根據領域模型，我們可以分析出系統大模塊總共分幾個部分，每個部分的核心領域對象是什麼，同時根據這個高內聚的領域對象分佈，我們很直關的就能歸納出一個實用性的領域劃分，如圖所示，我們可以簡單的將系統分爲用戶領域、商品領域和訂單領域，同時也能分析出，系統的核心域（訂單域、商品域）、通用域和支撐域（用戶域）。
![]()
-
第二板斧：領域服務和聚合根劃分
根據第一板斧的領域建模，我們可以得出一個簡單的領域模型，並根據這個領域模型進行了初步的領域劃分，到這裏，大家可以看到領域模型離項目落地還差了好多，系統有了骨架，接下來填充血肉，我們要對領域模型進行需求細節填充。
按照經驗，用戶域應該包含詳細信息、收貨地址、SSO等，商品域應包括詳細信息、SPU/SKU、供應商信息、品牌信息、商品圖片等，訂單應包括訂單詳情、訂單生命週期、收貨信息、商品評價等，最後形成一個比較詳細的領域模型網狀圖。
![]()
-
第三板斧：聚合、實體和值對象劃分
領域模型網狀圖畫出來之後，我們可以大致看出來整個系統的數據分佈和領域劃分，接下來我們繼續細化，細化分爲兩步：
- 把每一個子領域模型的具體屬性補充進去。
- 思考每一個聚合是否還有拆分的必要，如有必要則拆分爲實體和值對象。
到這裏我們就可以得到一張非常具體的數據庫ER圖，接下來可以根據這個ER圖進行具體的微服務劃分和數據建模。
![]()
3. DDD和數據驅動設計
數據驅動設計一般是先分析需求，提煉ER圖，ER圖提煉出來之後主要的設計工作就已經完成。
領域驅動設計是一個自上而下的過程，一般是從總體出發，先站在全局視角，分析業務領域和聚合根，劃分出核心域、通用域和支撐域，然後逐一分析子領域中的領域事件和數據聚合關係，搭建領域模型骨架，最後填充實體和值對象，形成一個個高內聚低耦合的領域模型。
然而在筆者看來，DDD和數據驅動設計並不是相互獨立的，在做DDD建模時，當我們拆分子領域完成後，在做子領域的數據建模時實際也是用戶數據驅動設計方法。
先使用DDD劃分子領域，再使用數據驅動設計進行數據建模。
4. DDD和微服務的關係
微服務是一種分佈式的技術架構模式，它主要是把一個大型的單體應用拆分成一個一個的獨立微小服務，微小服務間相互協調，共同支撐一個大系統的運行。
DDD根據界限上下文劃分出領域模型和領域服務，本身就可以實例化成一個個的微服務，通過領域驅動設計分析的系統天然支持微服務框架。
5. 寫在最後
架構設計方法論千千萬，DDD、數據驅動設計、MVC、N層架構、六邊形架構，適合自己的纔是最好的。
筆者一般做架構設計的習慣是：
- 先用DDD思想給系統劃分領域。
- 再用數據驅動設計提煉ER圖。
- 最後考慮業務場景確定工程代碼結構和分層結構。