# DDD 中的橋樑：透過有效建模與設計，從戰略走向戰術
講師: James Wang

---

分享目的: 提供一個實踐經驗提供給大家參考與討論

面對陌生的環境，先對周邊探索繪製手繪地圖，
隨著探索發現地圖也會更新與修正，
地圖成為航海家們的共通語言, 促進團隊間協作的橋樑, 透過建模的過程, 釐清問題的本質

## 模型: 連接問題空間 與 解決空間的橋樑
地圖是一個模型的表示, 模型表示了解決真實問題的解決方法的具體表示
將問題空間中的訊息需求轉化成策略和實踐

模型為了貼切解決問題, 需要持續的迭代來精鍊

## 從需求到實現：一個全面的探索過程
首先識別出具有商業價值的流程, 作為起點
透過繪製限界上下文地圖，將這些流程化分成不同的範疇, 並梳理這些範疇之間的關係
再進來進到每個範疇內, 進行細部討論與設計

## 戰略設計的產出 : Bounded Context
透過Event Storming的設計討論, 看見全貌後, 進而識別出Bounded context.

與特定領域有關系的系統

### 用業務流程串接 Bounded Contexts

### 動態與靜態 : 業務流程與 Context Map的結合
這裡能定義出職責
還能識別出"資訊"是如何在這些Bounded Contexts流轉的

PNR : Partner Ship(夥伴關係)
CF : 遵奉者模式, 需要follow上游的系統的規範來設計
OHS : Open/Host Service

更能全面的理解與設計系統，使其業務更具彈性

### Context Map Cheat Sheet

CF模式的合作下, 下游系統可能會需要設計出ACL防腐層, 防止因為上游的異動, 而影響到下游也需要跟著異動

電商與物流互動，服務之間是客戶與供應商模式，需要有清晰的界限和責任確保不會互相干擾，但還需要考慮流量、系統穩定性

## 服務間溝通：同步與非同步的選擇與影響

挑選出特定的服務流程, 來繪製出context map,
並且能討論出, 各服務(各bounded contexts)間的資料溝通是需要同步還是非同步, 才適合挑選出適當的技術選型

將剛剛討論好特定流程的context map, 進而討論出更多資料模型(read model, data, api, pub/sub events, ui, user stories...)
也順便達成共識

例如使用者用手機下訂單，可以由業務流程拆解紀錄，譬如可以記錄風險，在訂單延遲了可以通知使用者

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


在條列出領域事件後
將業務規則條列出來

## 將業務規則分組

我們要做的是捕捉領域專家的觀點，融入到設計與程式碼中

## 每群業務規則可視為聚合候選項



探索中的業務規則, 能夠精鍊成測試案例

## 驗證指標(Verification Metrics)

指標能夠幫助我們在營運時, 能指出是否需要調整策略, 進而滿足業務需求

## 非功能性需求

非功能性需求將影響運營中的系統有可靠性或更多關於成本或安全性的影響

* 安全性
* 效能
* 流量
* 併發
* 可用性
* 可維護性
* 可觀測性
* 容錯

## 架構設計
不只水平切分
能夠過boundex context進行垂直切分

## 總結

DDD 是**劃分邊界**的藝術
有了全貌, 有了各顆粒的邊界, 就能切分出各階段,並且組裝起來滿足真實世界問題的所需.
每個環節階段都能夠反映到領域知識，自由的 Zoom in/out 看到我們想看到的東西

## Q&A
A1 : 往下探討Aggregate的部份
A2 : 可以找業務單位, 客服單位; 或者從用戶在操作系統的角度, 搭配程式碼來反推

A1 : 要有足夠的**戰略設計的產出**, 團隊內部自己就能去主導戰術的規劃


A1 : 從物件的一連串狀態移轉, 來探索聚合根以及內部的聚合
A2 : 關注於當下即可, 除非已經知道未來業務流程或擴充上會如何變化了; 重點還是再有自動化測試, 在未來變化時, 才能過保過往的品質

A1 : yes
A2 : 分而自治, 才好估算出各個小元件的時程
A3 :