本文參考了我的同事肖然、王威和劉尚奇于2017年7月22日在ThoughtWorks北京辦公室所講授的“領域驅動的微服務架構設計——實戰工作坊”的課程內容，同時參考了我的同事亢江妹在業務分析工作中所使用的“拆分API故事”的實踐方法，在此表示感謝。

目的

領域驅動的微服務架構設計工作坊，能使軟件開發團隊所有成員在短時間內，迅速就新產品或遺留系統的價值、用戶畫像、關鍵場景、聚合達成一致，以便讓團隊快速識別軟件產品的問題域和解決方案域，發現微服務之間的API接口契約，并據此拆分微服務（或模塊）和團隊，來開發新產品或重構遺留系統。對于不打算實踐微服務的團隊拆分模塊也有參考意義。

步驟

準備

1）召集所有相關領域專家和開發團隊成員（包括：業務分析、開發、測試、DBA等）參加工作坊，準備大白紙、6種顏色（深黃-Domain Event、深藍-Command、深綠-aggregate、深粉-external system、紫-policy、淺黃-user）報事貼、藍丁膠和黑色三福記號筆。

事件風暴

產品價值

2）一起創建用戶畫像（姓名、年齡、職業、居住地、問題、目標；所見、所聽、所想和所感、痛點、目標）

得到App的用戶畫像

3）用電梯演講一起識別產品的核心賣點（差異化競爭優勢）

得到App的電梯演講

關鍵場景

4）繪制Use Case用例圖，識別其中核心賣點用例（粉色）、支撐用例（橙色）和通用用例（白色，用例即用戶目標），并按時間順序；注意識別Ubiquitous Language（領域普通話）

得到系統用例

命令風暴

5）選擇第一個核心賣點用例，按從左往右的順序用貼深藍報事貼的方式畫流程圖，圖中每一步都是值得“埋點”的命令（深藍）

“查看已購產品”流程圖

事件風暴

6）在流程圖上貼值得記錄日志的業務事件（深黃，有可能一個命令觸發多個事件，每個事件單獨寫一個報事貼）

在流程圖上貼深黃的業務事件

7）在相關事件處貼該事件所觸發的業務規則（紫）、該事件所源自的外部依賴系統（深粉），并在相關命令處貼該命令所源自的用戶（淺黃）

在相關事件處貼該事件所觸發的紫色的業務規則

聚合

8）在每個事件和命令之間貼聚合根（深綠），把具有相同生命周期（有助于維護業務一致性）和必須使用同步更新來實現數據完整性的聚合歸并為同一聚合根之下，并為該聚合根取名

把聚合歸并到聚合根之內

9）選擇核心賣點的下一個關鍵場景，重復第5）～第9），直到識別并歸并完所有的聚合

問題域和解決方案域

10）將各個聚合根據是否為業務核心賣點組織為子域，并識別核心子域、支撐子域和通用子域

粉紅背景的是核心子域，橙色背景的是支撐子域

11）將各個子域根據開發團隊的約束條件組織為限界上下文（每個限界上下文可以作為一個微服務），并識別各個限界上下文之間的關系（partnership, shared kernel, customer-supplier, conformist, anti-corruption layer, open host service, published language），拍照

識別限界上下文之間的關系

微服務之間的API接口契約

12）在關鍵場景流程圖下方，添加若干行，每一行貼一個深綠報事貼，代表一個相關的限界上下文
13）根據流程圖上的每一個事件，識別相應限界上下文為實現該事件所應對外提供的接口，拍照

API接口契約

各個微服務內部的用戶故事和驗收條件

14）根據限界上下文劃分團隊（這樣劃分的每個團隊就是一個微服務團隊），讓各個微服務團隊各自根據流程圖中所負責的事件，編寫用戶故事和驗收條件
15）各個微服務團隊識別其所負責的限界上下文內部的名詞（Aggregate Root, Entity, Value Object, Domain Events）和動詞（Services），并繪制實體關系圖，進行開發或重構

參考資料：

Domain-Driven Design
《領域驅動設計》
領域驅動的微服務架構設計——實戰工作坊
Domain-Driven Design Distilled
Introducing EventStorming