領域驅動設計戰略篇

Domain Driven Design(DDD) 分成戰略(Strategic)與戰術(Tactical)兩大塊。本次簡報專注於 DDD 戰略面議題，從企業面臨的問題，組織團隊面臨的問題，簡介透過事件風暴(EventStorming)工作坊解決實務常見問題。之後總結 DDD 戰略中最重要的兩個概念，分別是統一語言(Ubiquitous Language)與限界上下文(Bounded Context)。

此投影片適合剛入門想瞭解 DDD 的新手，認識 DDD 戰略，再學習 DDD 戰術才不容易走火入魔。

與另外一篇淺談領域驅動設計（連結 https://speakerdeck.com/jame2408/qian-tan-domain-driven-design ）切入視角不同，本篇較多著墨企業與組織問題。

Transcript

1. 領域驅動設計 戰略篇 James Wang
2. 關於我 ▪ I’m a programmer. ▪ Agile Community 與 Domain-Driven Taiwan 志工。 ▪ 學習領域驅動設計兩年多。
3. Outline 現實世界的問題 簡介 Domain-Driven Design（DDD） Domain-Driven Design（DDD）核心概念 1. 2. 3.
4. VUCA 霧卡 Volatility 變動性 Uncertainty 不確定性 Complexity 複雜性 Ambiguity 模糊性
5. Why I challenge VUCA and love the unknown
6. Enterprise face a challenging environment High customer expectations, fickleness Low barriers to entry Constant, rapid change and uncertainty … More
7. Enterprise Opportunity Enterprise Challenges
8. Way to deal with Complexity Problem Domain
9. Domain-Driven Design Can Help!
10. Domain-Driven Design 簡介 ▪ 我們看看提出 DDD 概念的 Eric Evans 的解釋： Tackling Complexity in the Heart of Software. 【軟體核心複雜度的解決方案】
11. Domain-Driven Design 價值 ▪ DDD 其重要價值是有系統地解構複雜的問題。 ▪ 什麼是複雜的問題？ The critical complexity of many software projects is in understanding the domain itself. 【軟體開發過程中，最為關鍵複雜根本的原因是目標領域本身就錯綜複雜】
12. 為什麼領域本身 錯綜複雜會是個 問題？ 思考問題背後的問題！
13. Domain-Driven Design 解決複雜領域問題的概念 ▪ 我們該如何面對複雜的領域？如何控制複雜呢？ Creative collaboration of software experts and domain experts. 【讓系統開發專家與領域專家協同合作】
14. Domain-Driven Design 解決方案 ▪ 團隊 / 利害關係人透過工作坊形式與領域專家訪談 – EventStorming – Domain Storytelling 我知道的 他知道的 他知道的 他知道的 透過工作坊，學習領域知識。 目標領域
15. 為什麼採用工作 坊形式？ 期望透過工作坊形式解決什麼問 題呢？
16. 我們先看看訪談者常遇到的問題 吃訪談者經驗與技巧，對領域知識要有一定程度掌握。
17. 我們先看看訪談者常遇到的問題 領域知識散落在各單位，整合不易。
18. 我們先看看訪談者常遇到的問題 訪談者與團隊間如何有效溝通？
19. 我們先看看訪談者常遇到的問題 訪談者與開發端的語言不一致 API…… …DB… UI. &@$ #~+ DATA 客單價分析… 損益表… 功能急需…
20. 我們先看看訪談者常遇到的問題 業務架構與系統架構不匹配
21. 我們需要工作坊解決這些問題
22. ENTER EVENTSTORMING 以事件風暴工作坊為範例講解
23. 簡介事件風暴（EVENTSTORMING）工作坊 ▪ 透過協作的方式對複雜的領域進行大規模的探索。 ▪ 軟體開發人員與業務人員一起建構整個業務線的行為模型。 – 確保所有關鍵人物（業務與技術關係人、引導者）都在同一個房間。 – 提供足夠長度的牆壁與便利貼。 – 讓大家以時間先後順序，使用領域事件呈現整個業務流程。
24. 事件風暴概覽 ▪ 用便利貼視覺化流程，透過團隊間多元觀點對話，分享與與學習 的場域。
25. 事件風暴工作坊三步驟 BIG PICTURE PROCESS MODELING SOFTWARE DESIGN
26. STEP 1：BIG PICTURE
27. 資料來源：Core Domain Patterns | by Nick Tune
28. Recap BIG PICTURE 凝聚眾人智慧，看見需求全貌，將複雜大問 題拆分成眾多小問題。 將小問題分類，優先解決重要的商業核心 問題。 逐一解決小問題，就沒有複雜的大問題了。
29. STEP 2：PROCESS MODELING
30. STEP 2：PROCESS MODELING
31. Recap PROCESS MODELING 豐富我們的事件。 邀請 UI / UX 人員一同參與設計。 選擇有價值的先做，不要忘記要解決的問 題與目標（GOAL）。
32. STEP 3：SOFTWARE DESIGN
33. STEP 3：SOFTWARE DESIGN BOUNDED CONTEXT 限界上下文 CONTEXT MAPPING 上下文映射
34. Recap SOFTWARE DESIGN 透過 Consistent Business Rule 形成 Aggregate。 將 Aggregate 透過業務性質相近的再收攏 成 Bounded Context。 Bounded Context 是從業務流程梳理而形 成的，也很自然的成為我們系統邊界。
35. 完成事件風暴工作坊 ▪ 輸入 Business Flow，輸出 Bounded Context 與 Context Mapping。 ▪ 透過交流，讓參與者對於 Business Flow 有一致性的理解與認知。 ▪ 下一步： – 找出最小可行性產品（Minimum Viable Product, MVP）。 – 依據 MVP 的 Bounded Context 進行建模與架構設計。 – 開發。 – 交付至市場，收取回饋再調整。
36. 看看現實中跑 EVENTSTORMING 狀況
37. 以 EventStorming 為範例 - 討論協同合作
38. 以 EventStorming 為範例 - 看見領域全貌
39. 以 EventStorming 為範例 - 找出 Bounded Context
40. 認識 Domain-Driven Design Overview & 兩大核心概念
42. 再深入解釋 DDD 重要的兩個概念
43. Bounded Context（BC） ▪ DDD 核心最重要概念之一。 DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
44. 透過 Bounded Context Canvas 切分 Bounded Context
45. 團隊與領域專家合作優點 • 一同瞭解複雜的領域全貌。 • 將複雜領域拆分成較小且易於解決的 Bounded Context。 • 建立團隊 Ubiquitous Language。 A language structured around the domain model and used by all team members to connect all the activities of the team with the software. 【一種圍繞領域模型構造的語言，所有團隊成員都使用該語言，將團隊所有 活動與系統聯繫起來。】 ... within a bounded context. 【...在限界上下文的範圍內。 】
46. Ubiquitous Language（UL） ▪ DDD 核心最重要概念之一。 在臺灣，代表 OK 沒有問題的意思。 在巴西，這是很粗魯的手勢。 Bounded Context Ubiquitous Language
47. Ubiquitous Language（UL）
48. DDD 戰略流程 Complexity Domain UL Bounded Context UL Bounded Context UL Bounded Context U U D D Stakeholders Domain Experts Event Storming Domain Storytelling
49. 認識 Domain-Driven Design 成功案例分享
50. Domain-Driven Design 知名案例 星巴克 獎勵平台：有 能力處理十 億個事件的 事件來源引 擎。 英國衛報 花費兩年時間， 將十多年老系 統全部翻新。 SalesForce 以 DDD 來面對 超過兩萬五千 個開發者協同 的複雜問題。
51. Domain-Driven Design 台灣趨勢 ▪ KKDay 於 2019 年引入事件風暴工作坊。 – 目的是加強業務團隊與技術人員協作時的共同理解。 ▪ 國泰金控與中國信託銀行於 2020 年投入更多實踐。 – 目標都是在既有系統能因應快速創新的需求下，能將既有資產、系統更好地 梳理業務流程，重整出高內聚、低耦合的一套有彈性的軟體。
52. 最後… 簡單總結
53. 建模 （聚合畫布） 今天簡單說了 Domain Driven Design 戰略部分 戰略 Strategic 戰術 Tactical • Bounded Context • Context Map • 系統開發相關 備註：戰略到戰術是持續迭代持續改進的流程。
54. 附上 DDD 簡單版流程
55. Ubiquitous Language UL UL UL U D D Bounded Context Bounded Context Bounded Context Stackholders Domain Experts Feedback Refactoring Coding Red Green Refactoring Modeling U Potentially Shippable Product Increment
56. 更多學習資源 ▪ 歡迎加入 Domain Driven Design Taiwan 社群。 https://tinyurl.com/ychs4x3w
57. Thank you! 感謝您的聆聽