淺談領域驅動設計

Slide 1

Slide 1 text

淺談領域驅動設計 James Wang

Slide 2

Slide 2 text

大家會遇到的問題 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

Slide 3

Slide 3 text

大泥球 • 架構設計不良，缺乏前期設計，使系統架構崩潰埋下隱患。 • 業務成長或需求不斷變化，架構變化過晚，使系統越來越複雜化。根源： • 將程式依據職責擺放。解決方法：

Slide 4

Slide 4 text

分層設計 User Interface Application Domain

Slide 5

Slide 5 text

只有分層還不夠

Slide 6

Slide 6 text

只有分層還不夠 + 垂直切割

Slide 7

Slide 7 text

Domain Model B 你還需要 Domain User Interface Application Domain Domain Model A User Interface Application Domain Domain Model C User Interface Application Domain 領域分割技術分割

Slide 8

Slide 8 text

你還需要 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. 如何溝通？

Slide 9

Slide 9 text

我們如何切分 Domain？

Slide 10

Slide 10 text

專案開始之初，首重看見全貌一旦；當你把眼光投注在哪一個要項的時候，實際上你就只看到那一部分，你的思緒將被那一部分的內容所牽動，很難再看見其他的事… 所以我們要退後一步，不! 有時要退後很多步，才能比較清晰地看見全貌。所以要調整範圍，試圖把我們在意的事放進視線可及之處，淡淡的審視它，不帶一點情緒，就是這樣，我們看見了全貌。 Source: 看見全貌 – Ruddy Lee 分享空間

Slide 11

Slide 11 text

從看見商業全貌開始（Big Picture） Goal Value 同理心地圖、價值主張地圖、商業模式畫布、 Impact Mapping… Scope EventStorming、 Domain Storytelling、 User Story Mapping…

Slide 12

Slide 12 text

商業全貌 - 以房貸商業流程為例顆粒非常的粗的商業流程。

Slide 13

Slide 13 text

浮現商業結構 Business Flow(Time) Emerging Bounded Contexts （Sub-Domain）

Slide 14

Slide 14 text

浮現商業結構 - 以房貸商業流程為例 Pivotal Events Swimlanes 相同流程，不同人分析，結果可能不同；或越深入了解領域知識，會持續調整邊界。所以切分商業流程沒有絕對，以團隊內當下共識為主。

Slide 15

Slide 15 text

浮現商業結構之其他判斷指標 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. 同樣的事物有不同用途這些指標，僅供參考。

Slide 16

Slide 16 text

浮現商業結構 - 房貸商業流程分類結果接待鑑價徵信授信帳務

Slide 17

Slide 17 text

浮現商業結構後 • 識別核心子領域、通用子領域、支撐子領域。 • 識別痛點。 • 識別風險或價值。 • 尋找價值流（Value Stream）。以上目的是尋找最小可行性產品（MVP），有價值的事情優先處理。下一步，流程建模（Process Modeling）。

Slide 18

Slide 18 text

流程建模其實就是挖掘更多業務細節，設計詳細的業務流程。挖掘更多細節，有助於更認識領域，會影響我們對於領域的切分。

Slide 19

Slide 19 text

從看見全貌到流程建模（Process Modeling）小明在星巴克看到限時買一送一的活動資訊，所以決定買咖啡，經過點餐結帳流程，最後完成購買，拿了兩杯咖啡離開。

Slide 20

Slide 20 text

流程建模 - 以房貸商業流程為例徵信 1. 此案例還能再往下細化，譬如如何建立信評模型？譬如徵信報告書格式與內容？譬如與 JCIC 系統溝通模式？ 2. 如果分析過程中遇到模糊或不確定內容，建議可以使用具體案例，透過舉例方式讓團隊達成共識。

Slide 21

Slide 21 text

當我們針對 MVP 逐一建立流程建模後徵信客戶帳務客戶鑑價客戶授信客戶發現「客戶」這概念重複出現在很多地方 1. 將「客戶」這概念提取出來 2. 將「客戶」這概念放在各服務中

Slide 22

Slide 22 text

團隊持續上述流程建模過程過程中，持續將雷同的概念聚合收攏。過程中，持續建立共識，並將討論中的各種用語記錄成詞彙表。過程中，別忘記目標，設計流程中識別出價值流。

Slide 23

Slide 23 text

Bounded Contexts - 以房貸商業流程為例客戶徵信授信鑑價帳務催收債協詞彙表詞彙表詞彙表詞彙表詞彙表詞彙表

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Sub-Domain VS Bounded Context Subdomain：Logic in the business flow Bounded Context：Value stream in the process Time

Slide 26

Slide 26 text

Domain 間如何溝通？

Slide 27

Slide 27 text

Context Map 定義：Context Maps describe the contact between bounded contexts and teams with a collection of patterns. 理想中，我們希望每個 Bounded Context 獨立自主提供業務服務（無耦合）。現實中，多個 Bounded Contexts 互相協作提供業務服務（低耦合）。所以接下來我們要識別出 Bounded Contexts 間的關連以及如何溝通。

Slide 28

Slide 28 text

Context Map - 識別上下游 U: Upstream 上游 D: Downstream 下游 BC BC BC U U D D Downstream 依賴於 Upstream 外部系統 D U

Slide 29

Slide 29 text

上下游間如何溝通的呢？ • Bounded Contexts 間的溝通需要中間件。

Slide 30

Slide 30 text

Bounded Contexts 間的溝通需要中間件使用 DB（不推薦）

Slide 31

Slide 31 text

Bounded Contexts 間的溝通需要中間件使用 HTTP 同步作法

Slide 32

Slide 32 text

Bounded Contexts 間的溝通需要中間件使用 Message 非同步作法

Slide 33

Slide 33 text

Bounded Contexts 間的溝通模式 RESTful HTTP Messaging Mechanism

Slide 34

Slide 34 text

REST Client Using an Anticorruption Layer Anticorruption Layer OHS / PL 上游下游

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

Context Map 上加上溝通模式 BC BC BC U U D D 外部系統 D U ACL ACL Queue 同步非同步

Slide 37

Slide 37 text

Source: Boris | VMware Tanzu Developer Center

Slide 38

Slide 38 text

Source: Boris | VMware Tanzu Developer Center

Slide 39

Slide 39 text

Recap - Domain 間如何溝通？

Slide 40

Slide 40 text

如何設計 Domain？

Slide 41

Slide 41 text

這章節議題很廣。我想講的是 Bounded Context 中的軟體架構設計。

Slide 42

Slide 42 text

軟體架構設計前言 • 每個 Bounded Context 間各自獨立自主管理，可以依據不同業務場景，不同 Bounded Contexts 設計不同架構。三層架構六角架構洋蔥架構簡潔架構

Slide 43

Slide 43 text

軟體架構設計核心分層相依

Slide 44

Slide 44 text

分層原則【高層】【低層】 Dependencies 低層級的具體細節組成的。轉接器、護城河核心商業邏輯變不變

Slide 45

Slide 45 text

依賴規則 Source code dependencies must point only inward, toward higher-level policies. 原始碼依賴關係只能指向內部，朝向更高層級的策略。

Slide 46

Slide 46 text

高層與低層的依賴規則有一個重要的規則：低層相依於框架和高層，高層不相依於任何人。依賴規則

Slide 47

Slide 47 text

【高層】【低層】 Dependencies Order Service Data Access Data Providers UI Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢訂單資料 Order Domain

Slide 48

Slide 48 text

【高層】【低層】 Dependencies Order Service Data Access Data Providers UI Web Api JSON JSON 依賴規則 – 舉個例子 User 我想查詢訂單資料 Order Domain <> IOrderRepository 透過依賴反轉讓相依永遠從低層指向高層

Slide 49

Slide 49 text

關於高層不相依任何人 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：意思是最高層一定沒有相依任何第三方套件嗎？

Slide 50

Slide 50 text

Recap 軟體架構設計原則 • 遵守分層與相依原則。 • 軟體架構設計是取捨，故打破上述原則也是 OK 的。 • 在原則底下，再思考流量、可用性、效能、可靠性、安全性、強健性、可擴展性、可維護性、彈性、易用性、… 等架構特性。

Slide 51

Slide 51 text

下一步，更細顆粒度的建模在此之前，要先了解以下知識： • Aggregate Root • Entity • Value Object • Domain Event • Domain Service • Application Service • Repository • …… 以上內容可以講個三天三夜，故有興趣的人可以找 DDD 的書學習。

Slide 52

Slide 52 text

最後想聊聊尖叫的架構

Slide 53

Slide 53 text

猜猜我是誰？猜猜我是誰 ├── 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 邦幫忙

Slide 54

Slide 54 text

尖叫的架構 • 軟體架構是輔助業務功能開發的工具，要讓架構能凸顯出業務功能本身。 • 若依據業務功能設計軟體架構，有需要隨時可以拆分服務，方便修改。猜猜我是誰 ├── catalog ├── inventory └── order ├── domain │ └── model │ └── order.ts ├── repository │ └── orderRepository.ts └── useCase Bounded Contexts 架構

Slide 55

Slide 55 text

總結

Slide 56

Slide 56 text

關於領域驅動設計 • 軟體開發的本質是滿足業務領域。 • 越複雜的領域，越需要被設計。 • 越複雜的領域越難設計，所以我們要將複雜的大問題拆分多個小問題。 • 小問題逐一解決，就沒有大問題了。 • 所謂領域驅動設計，核心就在拆分，確立各種邊界（Boundary）。從 Domain 到 Sub-Domains 到 Bounded Contexts 到 Aggregates，一路從戰略需求面到戰術實作面。 • 然而複雜領域無法一個人處理，所以要團隊大家與領域專家一起面對領域。

Slide 57

Slide 57 text

簡單的領域，或許你不需要領域驅動設計 Source: Implementing Domain-Driven Design

Slide 58

Slide 58 text

若專案分數在七分以上，推薦使用領域驅動設計 Source: Implementing Domain-Driven Design