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

Slide 1

Slide 1 text

DDD 中的橋樑透過有效建模與設計，從戰略走向戰術。 James Wang DDDesign Taiwan Conference 2023 0

Slide 2

Slide 2 text

關於我大家好，我是 James Wang，一位熱衷於探索新知並樂於分享的軟體工程師。同時，我也擔任台灣領域驅動設計社群的核心志工。 1

Slide 3

Slide 3 text

關於今天主題 2 戰略模型戰術

Slide 4

Slide 4 text

3 接下來的內容，不是答案，也不是唯一解。「設計」之路也沒有銀子彈，更沒有標準答案。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

模型：連接問題空間與解決空間的橋樑 6 真實世界（問題空間）理念世界（解決空間）領域模型

Slide 8

Slide 8 text

模型探索的漩渦過程：實踐中的模型迭代過程 7

Slide 9

Slide 9 text

從需求到實現：一個全面的探索過程 8 Source: ddd-starter-modelling-process-colored.png

Slide 10

Slide 10 text

戰略設計的產出：Bounded Context 9

Slide 11

Slide 11 text

用業務流程串接 Bounded Contexts 10 Source: domain-message-flow-modelling

Slide 12

Slide 12 text

動態與靜態：業務流程與 Context Map 的結合 11 Bounded Context Source: ddd-crew/bounded-context-canvas

Slide 13

Slide 13 text

動態與靜態：業務流程與 Context Map 的結合 12 Billing Context Billing Context Source: ddd-crew/bounded-context-canvas

Slide 14

Slide 14 text

Context Map Cheat Sheet 13 Source: ddd-crew/context-mapping

Slide 15

Slide 15 text

服務間溝通：同步與非同步的選擇與影響 14 Bounded Context Topic / Queue External System Async Sync Source: Boris | VMware Tanzu Developer Center

Slide 16

Slide 16 text

探索限界上下文：挖掘服務與能力 15 Source: Swift Method | VMware Tanzu Developer Center

Slide 17

Slide 17 text

接下來，來探索業務規則吧。回顧一下，什麼是限界上下文？ A bounded context is a defined part of software where particular terms, definitions and rules apply in a consistent way 16

Slide 18

Slide 18 text

在進入設計階段之前：混沌探索業務規則 17

Slide 19

Slide 19 text

將業務規則分組 18

Slide 20

Slide 20 text

每群業務規則可視為聚合候選項 19 candidates for aggregates

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

業務規則可視為測試案例，撰寫單元測試 21

Slide 23

Slide 23 text

接下來，還有什麼可以討論呢？我們探索需求放在地圖上從整個業務流程到切分子領域到找出限界上下文，然後識別各個限界上下文之間的互動與溝通模式。我們也探索了限界上下文中的業務規則，透過分群分組方式識別出聚合候選項。 22

Slide 24

Slide 24 text

驗證指標(Verification Metrics) 23 Build Measure Learn 訂單處理時間錯誤率轉換率 … 提供尋找驗證指標的幾項方法： 1. 與利害關係人一同討論，他們在乎什麼？ 2. 關鍵事件的轉換。 3. 狀態的變化。

Slide 25

Slide 25 text

非功能性需求 • 安全性 • 效能 • 流量 • 併發 • 可用性 • 可維護性 • 可觀測性 • 容錯 • …… 24

Slide 26

Slide 26 text

架構設計 25

Slide 27

Slide 27 text

總結 26

Slide 28

Slide 28 text

設計階段是團隊持續迭代的流程設計不是一個架構師或系統設計師全權負責的。也不是一次就能完成的任務。比較好的作法是，針對這次要衝刺的任務進行設計。 27

Slide 29

Slide 29 text

從大到小，從粗顆粒到細顆粒。能自由的 zoom in 與 zoom out。是決定邊界的藝術從領域切分子領域，識別出業務價值流程。到限界上下文到聚合。 28

Slide 30

Slide 30 text

如果將 DDD 的設計核心錯認是一種手段，而忘記了本質，就本末倒置了。不要忘記設計的本質。透過決定邊界的手段，產生一個「反映深層領域知識」並「聚焦於關鍵概念」的模型 29

Slide 31

Slide 31 text

你或許不需要這麼複雜的建模 30 今天講的內容，都是針對複雜的領域為出發點的。

Slide 32

Slide 32 text

Thank you! 31

Slide 33

Slide 33 text

參考資料 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

Slide 34

Slide 34 text

參考書籍 33