DDD 中的橋樑：透過有效建模與設計從戰略走向戰術

於 DDDesign Taiwan Conference 2023 的一場分享。

--

在 DDD 的世界裡，戰略和戰術是兩個不可或缺的元素。在戰略層面，我們投入大量心力去深入了解需求的本質、價值、目標，以及業務流程。我們將這些複雜、高度抽象的需求和問題進行拆解，轉化為更容易管理和實施的小單位。這個過程不僅讓團隊建立共識，而且促成了「ubiquitous language」的形成。

轉向戰術層面，我們努力確保系統架構與業務架構的高度一致性。我們探討如何在程式碼中實現「ubiquitous language」，並深入研究各種程式設計原則和最佳實踐。

然而，一個相對少被提及但極為關鍵的問題是，如何將戰略和戰術有效地串接起來？這個串接過程，或者說，這座橫跨戰略和戰術的「橋樑」，正是我今天要與大家深入探討的主題。

Transcript

1. DDD 中的橋樑 透過有效建模與設計，從戰略走向戰術。 James Wang DDDesign Taiwan Conference 2023 0
2. 關於我 大家好，我是 James Wang，一位熱衷於 探索新知並樂於分享的軟體工程師。同 時，我也擔任台灣領域驅動設計社群的 核心志工。 1
3. 關於今天主題 2 戰略 模型 戰術
4. 3 接下來的內容，不是答案，也不是唯一解。 「設計」之路也沒有銀子彈，更沒有標準答案。
7. 模型：連接問題空間與解決空間的橋樑 6 真實世界 （問題空間） 理念世界 （解決空間） 領域模型
8. 模型探索的漩渦過程：實踐中的模型迭代過程 7
9. 從需求到實現：一個全面的探索過程 8 Source: ddd-starter-modelling-process-colored.png
10. 戰略設計的產出：Bounded Context 9
11. 用業務流程串接 Bounded Contexts 10 Source: domain-message-flow-modelling
12. 動態與靜態：業務流程與 Context Map 的結合 11 Bounded Context Source: ddd-crew/bounded-context-canvas
13. 動態與靜態：業務流程與 Context Map 的結合 12 Billing Context Billing Context Source: ddd-crew/bounded-context-canvas
14. Context Map Cheat Sheet 13 Source: ddd-crew/context-mapping
15. 服務間溝通：同步與非同步的選擇與影響 14 Bounded Context Topic / Queue External System Async Sync Source: Boris | VMware Tanzu Developer Center
16. 探索限界上下文：挖掘服務與能力 15 Source: Swift Method | VMware Tanzu Developer Center
17. 接下來，來探索業務規則吧。 回顧一下，什麼是限界上下文？ A bounded context is a defined part of software where particular terms, definitions and rules apply in a consistent way 16
18. 在進入設計階段之前：混沌探索業務規則 17
19. 將業務規則分組 18
20. 每群業務規則可視為聚合候選項 19 candidates for aggregates
22. 業務規則可視為測試案例，撰寫單元測試 21
23. 接下來，還有什麼可以討論呢？ 我們探索需求放在地圖上 從整個業務流程到切分子領域到找出限界上下文，然後 識別各個限界上下文之間的互動與溝通模式。 我們也探索了限界上下文中的業務規則，透過分群分組 方式識別出聚合候選項。 22
24. 驗證指標(Verification Metrics) 23 Build Measure Learn 訂單 處理時間 錯誤率 轉換率 … 提供尋找驗證指標的幾項方法： 1. 與利害關係人一同討論，他們在乎什麼？ 2. 關鍵事件的轉換。 3. 狀態的變化。
25. 非功能性需求 • 安全性 • 效能 • 流量 • 併發 • 可用性 • 可維護性 • 可觀測性 • 容錯 • …… 24
26. 架構設計 25
27. 總結 26
28. 設計階段是團隊持續迭代的流程 設計不是一個架構師或系統設計師全權負責的。 也不是一次就能完成的任務。 比較好的作法是，針對這次要衝刺的任務進行設計。 27
29. 從大到小，從粗顆粒到細顆粒。 能自由的 zoom in 與 zoom out。 是決定邊界的藝術 從領域切分子領域，識別出業務價值流程。 到限界上下文到聚合。 28
30. 如果將 DDD 的設計核心錯認是一種手 段，而忘記了本質，就本末倒置了。 不要忘記設計的本質。 透過決定邊界的手段，產生一個「反映深層領域知 識」並「聚焦於關鍵概念」的模型 29
31. 你或許不需要這麼複雜的建模 30 今天講的內容，都是針對複雜的領域為出發點的。
32. Thank you! 31
33. 參考資料 1. Whirlpool Process of Model Exploration - Domain Language 2. GitHub - ddd-crew/ddd-starter-modelling-process: If you're new to DDD and not sure where to start, this process will guide you step-by-step 3. GitHub - ddd-crew/bounded-context-canvas: A structured approach to designing and documenting each of your bounded contexts 4. GitHub - ddd-crew/context-mapping 5. Boris | VMware Tanzu Developer Center 6. EventStorming 7. Getting modules right with Domain-driven Design - Speaker Deck 8. Start Your Architecture Modernization with Domain-Driven Discovery (infoq.com) 32
34. 參考書籍 33