作者：小傅哥
部落格：https://bugstack.cn
沉澱、分享、成長，讓自己和他人都能有所收穫！😄
大家好，我是技術UP主小傅哥。
👨🏻💻 經過5.1假期的一頓框框輸出，終於完成了《大營銷專案》第二階段的開發和上線，體驗地址：https://gaga.plus 有了這個專案的落地，也終於可以給大家完整的梳理出一套 DDD 落地指引規範。包括；戰略、戰術、戰役，各個階段都要做什麼，怎麼做風暴模型和四色建模。有了這套東西參考，小白也能目標明確的做 DDD 專案開發啦！
我一直講，要先實踐，再理論！
程式設計，偏理科的東西要先上手實踐，再做理論理解。因為所有的理論提出，也都是建立有了實踐結果後，抽象出來的理論。但你上來就要用理論去反推結果，並不是一件容易的事情。就像不少的 DDD 文章，往往會用一個理論，去講另外一個理論，這也導致很多沒有實踐過的小白夥伴，壓根不知道講的是什麼。最終覺得 DDD 太難！
所以在近2年的時間裡，小傅哥分享了非常多的 DDD 實踐內容，包括；DDD 工程結構&腳手架、各項分散式技術棧在 DDD 結構下的使用、DDD 實戰專案&小場景訓練。這些內容都可以在 bugstack.cn 學習。
接下來，小傅哥會帶著你走一遍研發設計評審，講解 DDD 落地專案的全部過程。
文末有對應本專案的 DDD 工程程式碼地址，理論 + 程式碼 + 影片，學的嘎嘎透徹！
一、戰略、戰術、戰役
首先 DDD 是一種軟體設計方法，Domain-driven design (DDD) is a major software design approach. 來自維基百科。軟體設計方法涵蓋了；正規化、模型、框架、方法論，主要活動包括建模、測試、工程、開發、部署、維護。來自維基百科的軟體設計涵蓋資訊介紹。
在 DDD 領域驅動設計中，常提到戰略、戰術，和一少部分會講到戰役。這3個詞主要講的是不同的開發階段所需要完成的事項；
- 戰略 - 建模；領域劃分、界限上下文、核心領域
- 戰術 - 架構；工程結構、領域物件、領域服務、領域事件
- 戰役 - 編碼；設計原則、設計模式
DDD 的戰略、戰術和戰役設計相輔相成，戰略提供系統的建模作為宏觀指導，戰術下面有N個戰役，兩者則關注具體的實現和編碼落地。
在維基百科中有不少 DDD 非常好的資料，其中一個是關於事件風暴的，講解了執行戰略設計中風暴模型的步驟。
有了這基礎認知，接下來我們透過《大營銷專案》從需求到設計，一步步瞭解系統的領域驅動設計。
二、產品需求
1. 產品訴求
如圖，是一個複雜的營銷抽獎場景玩法需求，涵蓋了；活動配置、簽到&獎勵、活動賬戶、抽獎策略「責任鏈+規則樹」、庫存扣減、抽獎滿N次後階梯抽獎等。面對這樣的複雜系統，非常適合使用 DDD 落地。
分析需求；
- 整體機率相加，總和為1或者分值計算，機率範圍千分位
- 抽獎為免費抽獎次數 + 使用者消耗個人積分抽獎
- 抽獎活動可給使用者分配可抽獎次數，透過點選簽到發放
- 活動延伸配置使用者庫存消耗管理，單獨提供表配置各類庫存
使用者可用總庫存、使用者可用日庫存 - 部分抽獎規則，需要抽獎n次後解鎖，才能有機會抽取
- 抽獎完成增加（運氣值/積分值/抽獎次數）記錄，讓使用者獲得獎品。
- 獎品對接，自身的積分、內部系統的獎品
- 隨機積分，發給你積分。
- 黑名單使用者抽獎，則給予固定的獎品。
2. 業務流程
依照於產品需求，在產品的 PRD 文件中還會繪製出業務流程圖。產品的流程圖會比較粗一些，研發後期需要根據產品的 PRD 文件做具體的設計。
- 產品經理會詳細的介紹整個系統的功能流程和需要對接介面文件。
- 以上就是以使用者旅程為維度，從點選簽到獲得活動賬戶額度，再到一些列抽獎、抽獎策略、中獎結果和獎品發放的流程。
三、系統架構
如果首次承接的是一個新的系統，還需要對系統進行架構設計，是單體架構還是分散式架構，以及所要用到的技術棧。最好在提供好相關的落地案例和DDD腳手架。—— 沒有這些東西，就想說點理論，就讓團隊用DDD寫程式碼，那就是天方夜譚！你都沒寫出DDD程式碼，兄弟👬🏻哪裡去複製！
資料：—— 詳細介紹了 DDD 落地的案例和通用的腳手架。
- DDD 架構：https://bugstack.cn/md/road-map/ddd.html
- MVC2DDD：https://bugstack.cn/md/road-map/mvc2ddd.html
- DDD 腳手架：https://bugstack.cn/md/road-map/ddd-archetype-maven.html
1. 分散式架構
2. 分散式技術
四、戰略設計
不少夥伴，都講過不知道怎麼開始 DDD，主要是拿到一個需求，不知道從哪下手，也不知道那些領域的模型是怎麼弄出來的。好，這次小傅哥就給你整個完整的案例，告訴你如何開始。
1. 用例圖
根據業務需求畫系統用例圖；
- 用例圖（英語：use case diagram）是使用者與系統互動的最簡表示形式，展現了使用者和與他相關的用例之間的關係。透過用例圖，人們可以獲知系統不同種類的使用者和用例。用例圖也經常和其他圖表配合使用。
- 用例圖，也可以等同於是使用者故事（英語：User story）（軟體開發和專案管理中的常用術語），主旨是以日常語言或商務用語撰寫句子，是一段簡單的功能表述。以客戶或使用者的觀點撰寫下有價值的功能、引導、框架來與使用者進行互動，進而推動工作程序。可以被認為是一種規格檔案，但更精確而言，它代表客戶的需求與方向。以該使用者故事來反應物件在組織內的其工作職責、範圍、需要進行的任務等。使用者故事在敏捷開發方法中用來定義系統需要提供的功能和實現需求管理。
- 儘管用例本身會涉及大量細節和各種可能性，用例圖卻能提綱挈領地讓人瞭解系統概況。它為“系統做什麼”提供了簡化了的圖形表示，因此被譽為“搭建系統的藍圖”。
2. 事件風暴定義
在使用 DDD 的標準對系統建模前，一堆人要先了解 DDD 的操作手段，這樣才能讓產品、研發、測試、運營等了解業務的夥伴，都能在同一個語言下完成系統建模。
- 藍色 - 決策命令，是使用者發起的行為動作，如；開始簽到、開始抽獎、檢視額度等。
- 黃色 - 領域事件，過去時態描述。如；簽到完成、抽獎完成、獎品發放完成。它所闡述的都是這個領域要完成的終態。
- 粉色 - 外部系統，如你的系統需要呼叫外部的介面完成流程。
- 紅色 - 業務流程，用於串聯決策命令到領域事件，所實現的業務流程。一些簡單的場景則直接有決策命令到領域事件就可以了。
- 綠色 - 只讀模型，做一些讀取資料的動作，沒有寫庫的操作。
- 棕色 - 領域物件，每個決策命令的發起，都是含有一個對應的領域物件。
👩🏻🏫敲黑板 綜上，左下角的示意圖。就是一個使用者，透過一個策略命令，使用領域物件，透過業務流程，完成2個領域事件，呼叫1次外部介面個過程。我們在整個 DDD 建模過程中，就是在尋找這些節點。
3. 尋找領域事件
接下來，大量的時間，都是在挖掘領域事件。這個過程就是一堆人頭腦風暴的過程，避免錯失流程節點。
- 根據產品 PRD 文件，一起開會梳理有哪些領域事件。其實大多數領域事件一個人都可以想到，只是有些部分小的場景和將來可能產生的事件不一定覆蓋全。所以要透過產品、測試、以及團隊的架構師，一起討論。
- 像是整個大營銷的抽獎會包括如圖所列舉的事件。在列舉這個階段，你用在乎格式。也可以是每個人準備好黃色便籤紙，想到一個就貼到黑板上一個，只是窮舉完成。—— 實際做DDD中，也是這樣用便籤紙貼黑板，所以用不同的顏色做區分。
4. 識別領域角色和物件
在確定了領域事件以後，接下來要做的就是透過決策命令串聯領域事件，並填充上所需要的領域物件。這塊的操作，新手可以分開處理，如先給領域事件新增決策命令、執行使用者和領域物件，最後在串聯流程。就像 事件風暴定義 中的示意一樣。
- 首先，透過使用者的行為動作，也就是決策命令，串聯到對應的領域事件上。並對複雜的流程提供出紅色的業務流程。
- 之後，為決策命令新增領域物件，每一個領域在整個流程中都起到了至關重要的作用。
5. 劃分領域邊界
有了識別出來的領域角色的流程，就可以非常容易的劃分出領域邊界了。先在事件風暴圖上圈出領域邊界，之後在單獨提供領域劃分。
5.1 圈出領域
5.2 領域邊界
- 到這步咱們就可以獲得整個專案中 DDD 的領域邊界劃分了。之後再往下就是具體的每個領域物件的詳細設計和流程設計。
6. 研發詳細設計
6.1 實體物件
- 你需要對每一個領域物件進行欄位的詳細設計。並劃分出它們的上下文關係。一般在公司中，這部分設計完成，其他人也能對照你的設計進行程式碼開發。
6.2 流程設計
- 流程設計，就是更詳細的設計了。每一步要呼叫到哪個系統，哪個介面，要執行什麼動作就全部都有了。
五、工程實現
DDD 的戰略設計做完，劃分出領域邊界以後。接下來就是要執行戰術和戰役了。也就是在工程中做編碼實現。但一定要懂得設計原則和設計模式，否則寫不出好的程式碼的。
- 工程實現，就是在確定的框架結構中編碼。可以是洋蔥架構、整潔架構、菱形架構等等。這部分內容的可以透過實戰專案來鍛鍊，獲得編碼技巧。