淺談領域驅動設計

本次受邀參加【蔣幹話軟體】邀約，線上淺談一場領域驅動設計（Domain Driven Design, DDD）。

本次從軟體架構切入，從領域分析談到設計，帶出整個戰略流程的講解，歡迎大家共同討論。

Transcript

1. 淺談 領域驅動設計 James Wang
2. 大家會遇到的問題 A big ball of mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling- wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. —Brian Foote and Joseph Yoder
3. 大泥球 • 架構設計不良，缺乏前期設計，使系統架構崩潰埋下隱患。 • 業務成長或需求不斷變化，架構變化過晚，使系統越來越複雜化。 根源： • 將程式依據職責擺放。 解決方法：
4. 分層設計 User Interface Application Domain
5. 只有分層還不夠
6. 只有分層還不夠 + 垂直切割
7. Domain Model B 你還需要 Domain User Interface Application Domain Domain Model A User Interface Application Domain Domain Model C User Interface Application Domain 領域分割 技 術 分 割
8. 你還需要 Domain – BUT! Domain Model B User Interface Application Domain Domain Model A User Interface Application Domain Domain Model C User Interface Application Domain 1. 我們如何切分 Domain？ 2. Domain 間如何 溝通？ 3. 我們如何設計 Domain？ 1. 如何切分？ 3. 如何設計？ 2. 如何溝通？
9. 我們如何切分 Domain？
10. 專案開始之初，首重看見全貌 一旦；當你把眼光投注在哪一個要項的時候，實際上你就只看到那一部分， 你的思緒將被那一部分的內容所牽動，很難再看見其他的事… 所以我們要退後一步， 不! 有時要退後很多步，才能比較清晰地看見全貌。 所以要調整範圍，試圖把我們在意的事放進視線可及之處， 淡淡的審視它，不帶一點情緒，就是這樣，我們看見了全貌。 Source: 看見全貌 – Ruddy Lee 分享空間
11. 從看見商業全貌開始（Big Picture） Goal Value 同理心地圖、 價值主張地圖、 商業模式畫布、 Impact Mapping… Scope EventStorming、 Domain Storytelling、 User Story Mapping…
12. 商業全貌 - 以房貸商業流程為例 顆粒非常的粗的商業流程。
13. 浮現商業結構 Business Flow(Time) Emerging Bounded Contexts （Sub-Domain）
14. 浮現商業結構 - 以房貸商業流程為例 Pivotal Events Swimlanes 相同流程，不同人分析，結果可能不同； 或越深入了解領域知識，會持續調整邊界。 所以切分商業流程沒有絕對，以團隊內當下共識為主。
15. 浮現商業結構之其他判斷指標 1. Activities that only involve one actor. 只有一個參與者，獨自做了許多事 2. One-way information flow. 單向資訊流 3. Different triggers. 不同的觸發點 4. Activities supporting something that is not in the picture. 不屬於這個領域故事的活動行為 5. Differences in language. 同樣的事物有不同的名稱 6. Different use of the same thing. 同樣的事物有不同用途 這些指標，僅供參考。
16. 浮現商業結構 - 房貸商業流程分類結果 接待 鑑價 徵信 授信 帳務
17. 浮現商業結構後 • 識別核心子領域、通用子領域、支撐子領域。 • 識別痛點。 • 識別風險或價值。 • 尋找價值流（Value Stream）。 以上目的是尋找最小可行性產品（MVP），有價值的事情優先處理。 下一步，流程建模（Process Modeling）。
18. 流程建模 其實就是挖掘更多業務細節，設計詳 細的業務流程。 挖掘更多細節，有助於更認識領域， 會影響我們對於領域的切分。
19. 從看見全貌到流程建模（Process Modeling） 小明在星巴克看到限時買一送一的活動資訊， 所以決定買咖啡，經過點餐結帳流程，最後完成購買， 拿了兩杯咖啡離開。
20. 流程建模 - 以房貸商業流程為例 徵信 1. 此案例還能再往下細化，譬如如何建立信評模型？譬如徵信報告書格式 與內容？譬如與 JCIC 系統溝通模式？ 2. 如果分析過程中遇到模糊或不確定內容，建議可以使用具體案例，透過 舉例方式讓團隊達成共識。
21. 當我們針對 MVP 逐一建立流程建模後 徵信 客 戶 帳務 客 戶 鑑價 客 戶 授信 客 戶 發現「客戶」這概念重複出現在很多地方 1. 將「客戶」這概念提取出來 2. 將「客戶」這概念放在各服務中
22. 團隊持續上述流程建模過程 過程中，持續將雷同的概念聚合收攏。 過程中，持續建立共識，並將討論中的各種用語記錄成詞彙表。 過程中，別忘記目標，設計流程中識別出價值流。
23. Bounded Contexts - 以房貸商業流程為例 客戶 徵信 授信 鑑價 帳務 催收 債協 詞 彙 表 詞 彙 表 詞 彙 表 詞 彙 表 詞 彙 表 詞 彙 表
24. Recap - 我們如何切分 Domain？ • 從商業流程（Business Flow）下手。 • 區分子領域（ Sub-Domain / Emerging Bounded Contexts）。 • 探討細部流程（Processes）。 • 從細部流程中識別價值流程（Value Stream）。 • 基於以上基礎下，歸納統整出限界上下文（Bounded Contexts）。 A bounded context is the boundary of a model that represents those concepts, their relationships, and their rules. The same subdomain could be represented by an infinite number of modelling choices. Source: Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined | by Nick Tune
25. Sub-Domain VS Bounded Context Subdomain：Logic in the business flow Bounded Context：Value stream in the process Time
26. Domain 間 如何溝通？
27. Context Map 定義：Context Maps describe the contact between bounded contexts and teams with a collection of patterns. 理想中，我們希望每個 Bounded Context 獨立自主提供業務服 務（無耦合）。 現實中，多個 Bounded Contexts 互相協作提供業務服務（低 耦合）。 所以接下來我們要識別出 Bounded Contexts 間的關連以及如 何溝通。
28. Context Map - 識別上下游 U: Upstream 上游 D: Downstream 下游 BC BC BC U U D D Downstream 依賴於 Upstream 外部系統 D U
29. 上下游間如何溝通的呢？ • Bounded Contexts 間的溝通需要中間件。
30. Bounded Contexts 間的溝通需要中間件 使用 DB（不推薦）
31. Bounded Contexts 間的溝通需要中間件 使用 HTTP 同步作法
32. Bounded Contexts 間的溝通需要中間件 使用 Message 非同步作法
33. Bounded Contexts 間的溝通模式 RESTful HTTP Messaging Mechanism
34. REST Client Using an Anticorruption Layer Anticorruption Layer OHS / PL 上游 下游
35. Integration Using Message Context A Context B Event Bus Outbox Outbox Inbox Inbox Event Handler Event Handler Source: GitHub - kgrzybek/modular-monolith-with-ddd: Full Modular Monolith application with Domain-Driven Design approach.
36. Context Map 上加上溝通模式 BC BC BC U U D D 外部系統 D U ACL ACL Queue 同步 非同步
37. Source: Boris | VMware Tanzu Developer Center
38. Source: Boris | VMware Tanzu Developer Center
39. Recap - Domain 間如何溝通？
40. 如何設計 Domain？
41. 這章節議題很廣。 我想講的是 Bounded Context 中的軟體架構設計。
42. 軟體架構設計前言 • 每個 Bounded Context 間各自獨立自主管理，可以依據不同業務場景， 不同 Bounded Contexts 設計不同架構。 三層架構 六角架構 洋蔥架構 簡潔架構
43. 軟體架構設計核心 分層 相依
44. 分層原則 【高層】 【低層】 Dependencies 低層級的具體 細節組成的。 轉接器、護城河 核心商業邏輯 變 不變
45. 依賴規則 Source code dependencies must point only inward, toward higher-level policies. 原始碼依賴關係只能指向內部，朝向更高層級的策略。
46. 高層與低層的依賴規則 有一個重要的規則： 低層相依於框架和高層， 高層不相依於任何人。 依賴規則
47. 【高層】 【低層】 Dependencies Order Service Data Access Data Providers UI Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢 訂單資料 Order Domain
48. 【高層】 【低層】 Dependencies Order Service Data Access Data Providers UI Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢 訂單資料 Order Domain <<Interface>> IOrderRepository 透過依賴反轉讓相依永遠從低層指向高層
49. 關於高層不相依任何人 I have accepted Log4Net into the core because of its history of stability and small surface area. - Jeffrey Palermo 洋蔥架構提出者 Q：意思是最高層一定沒有相依任何第三方套件嗎？ I have accepted Log4Net into the core because of its history of stability and small surface area. - Jeffrey Palermo 洋蔥架構提出者 Q：意思是最高層一定沒有相依任何第三方套件嗎？
50. Recap 軟體架構設計原則 • 遵守分層與相依原則。 • 軟體架構設計是取捨，故打破上述原則也是 OK 的。 • 在原則底下，再思考流量、可用性、效能、可靠性、安全性、強健性、可 擴展性、可維護性、彈性、易用性、… 等架構特性。
51. 下一步，更細顆粒度的建模 在此之前，要先了解以下知識： • Aggregate Root • Entity • Value Object • Domain Event • Domain Service • Application Service • Repository • …… 以上內容可以講個三天三夜，故有興趣的人可以找 DDD 的書學習。
52. 最後想聊聊尖 叫的架構
53. 猜猜我是誰？ 猜猜我是誰 ├── catalog ├── inventory └── order ├── domain │ └── model │ └── order.ts ├── repository │ └── orderRepository.ts └── useCase ├── createOrder.ts ├── getOrderList.ts └── updateOrder.ts 猜猜我是誰 ├── api ├── application └── domain ├── aggregate │ └── order │ └── order.ts │ └── orderIdVO.ts │ └── catalog │ └── catalog.ts │ └── inventory └── service Source: 軟體架構淺談 - iT 邦幫忙
54. 尖叫的架構 • 軟體架構是輔助業務功能開發的工具，要讓架構能凸顯出業務功能本身。 • 若依據業務功能設計軟體架構，有需要隨時可以拆分服務，方便修改。 猜猜我是誰 ├── catalog ├── inventory └── order ├── domain │ └── model │ └── order.ts ├── repository │ └── orderRepository.ts └── useCase Bounded Contexts 架構
55. 總結
56. 關於領域驅動設計 • 軟體開發的本質是滿足業務領域。 • 越複雜的領域，越需要被設計。 • 越複雜的領域越難設計，所以我們要將複雜的大問題拆分多個小問題。 • 小問題逐一解決，就沒有大問題了。 • 所謂領域驅動設計，核心就在拆分，確立各種邊界（Boundary）。從 Domain 到 Sub-Domains 到 Bounded Contexts 到 Aggregates，一路 從戰略需求面到戰術實作面。 • 然而複雜領域無法一個人處理，所以要團隊大家與領域專家一起面對領域。
57. 簡單的領域，或許你不需要領域驅動設計 Source: Implementing Domain-Driven Design
58. 若專案分數在七分以上，推薦使用領域驅動設計 Source: Implementing Domain-Driven Design
59. 最後 好的軟體架構是適當的精心設計與不斷的演化而來的。
60. Thank you for listening.