把一個模糊功能需求轉成可部署的後端與前端，中間有一段工程師最容易跳過的步驟：把領域（domain）想清楚。這個專欄把四套方法論串成一條可操作的流程，每一步都有具體輸入與輸出 artifact，讓 AI agent 能直接接手執行。
流程全景
Event Storming（協作探索領域）
│ 輸出：Domain Events、Commands、Aggregates、Bounded Contexts、Hotspots
▼
Problem Frames（框定子問題 + 顯性化假設） ← 輔助/補強，連到既有專欄
│ 輸出：frame.md、W Register（Domain Assumptions）、S∧W⊨R 驗證
▼
Event Sourcing / CQRS（後端落地）
│ 輸出：Event Store 設計、Aggregate 狀態機、Projections（Read Models）
▼
前端從領域模型推導
│ 輸出：UI ↔ Read Model 對應圖、Command ↔ 用戶行為對應、共享型別定義
▼
Pattern Language（固化重複解法）
輸出：Pattern Catalog（命名 + 情境 + forces + 解法 + 關聯）
Problem Frames 在這條流程裡扮演輔助角色——把 Event Storming 挖出的事件與邊界，轉成可形式化檢查的規格與顯性假設（W Register）。詳細說明見 Problem Framing ＋ Spec-Driven Development 專欄；這裡只用 wikilink 帶過，不重複長篇。
四套方法論的角色分工
| 方法論 | 在流程中的角色 | 主要輸出 |
|---|---|---|
| Event Storming | 起點：把領域從混沌帶到清晰的 Bounded Contexts | 事件清單、聚合邊界、上下文地圖 |
| Problem Frames | 補強：把子問題形式化，顯性化 AI 容易默默假設的事 | frame.md、W Register |
| Event Sourcing / CQRS | 後端：以事件為真相來源，讀寫分離 | Event Store、Read Models |
| Pattern Language | 沉澱：把上述結果萃取成可重用、可命名的設計詞彙 | Pattern Catalog |
學習路徑
探索與建模
- Event Storming：協作式領域探索 — Big Picture / Process / Design 三層；Domain Events → Commands → Aggregates → Bounded Contexts；工作坊 artifact
- Problem Frames 形式化 → kiro-frame：Problem Frames 形式化工具（既有專欄）
後端落地
- Event Sourcing + CQRS：後端落地 — Event 為真相來源；Event Store、Projection、Read/Write 分離；適用時機與代價
前端推導
- 前端從領域模型推導 — Read Models 驅動 UI 組件；共享詞彙消除前後端阻抗；事件驅動 UI 狀態
設計詞彙固化
- Pattern Language：沉澱可重用設計詞彙 — Alexander 的 pattern 結構；DDD 典型 patterns；如何為自己領域寫 pattern catalog
實戰
- 完整流程實戰：電商訂單系統走一遍 — 從需求到 Pattern Catalog，每步輸入/輸出 artifact 逐一示範
與 cc-sdd / kiro-frame 的關係
cc-sdd（spec-driven pipeline）的輸入是「一個清楚的 feature spec」。這條流程的產出，正是生成那份 spec 所需要的領域模型素材——聚合邊界、命令語意、不變量、讀模型結構——可直接接進 /kiro-spec-requirements。
本流程輸出 → cc-sdd 輸入
Bounded Contexts → spec 的 scope boundary
Aggregates + Commands → requirements 的動詞結構
W Register → assumptions 段落
Read Models → API contract 的 response shape
Pattern Catalog → design decisions 段落
🔍 待解問題 / 持續追蹤
- Big Picture Event Storming 需要真人協作（Brandolini 設計它時有這個前提）；純 AI 輔助的 Event Storming（由 AI 扮演多個領域角色對話）目前沒有成熟實踐，是個開放實驗方向。
- Event Sourcing 的 schema evolution（事件版本升級）業界有幾個模式（upcasting、event folding、weak schema），但沒有「唯一正確」方法，選哪個取決於 append 頻率與查詢模式。
- Pattern Language 的「forces」欄位在軟體脈絡下比建築脈絡更難寫——軟體的 force 往往是業務約束，不是物理限制；如何讓 force 段落對 AI agent 有可操作的指導，仍在實驗。
- 前後端共享 Read Model 型別的最佳工具鏈（GraphQL schema、TypeScript shared types、OpenAPI spec）依環境而異；這條流程目前對工具中立，只描述概念層次。
- Event Storming 工作坊在遠端環境（Miro / Figma / FigJam）的效果是否等同於實體便利貼，業界意見分歧；Brandolini 個人傾向實體，但大量團隊已採用線上工具。
🕒 更新紀錄
- 2026-07-02 — 建立專欄。含 hub 與五篇原子筆記：Event Storming 領域探索、Event Sourcing+CQRS 後端落地、前端從領域模型推導、Pattern Language 設計詞彙、完整流程實戰走一遍。