Pattern Language 是這條流程的最後一步，也是最常被跳過的一步。Event Storming、Event Sourcing、前端推導——這些做完後，你手上有一套可以跑的系統；但如果不做這步，下次遇到類似問題時，你要從頭再想一遍。Pattern Language 把「這次怎麼解」沉澱成「這類問題怎麼解」——一個可命名、可傳達、可被 AI agent 引用的設計詞彙。
源起：Alexander 的 Pattern Language
Christopher Alexander 在 1977 年出版《A Pattern Language》（Oxford University Press），描述 253 個建築與城市設計 pattern，從城市規模（城市、街區、廣場）到建築細節（窗台高度、走廊寬度）。
每個 pattern 的結構是：
名稱（Name）
情境（Context）：這個 pattern 適用的環境
Forces：相互衝突、讓問題難以解決的力量
解法（Solution）：一個平衡 forces 的設計方案
後果（Consequences）：採用這個解法帶來的取捨
關聯（Related Patterns）：與其他 pattern 的連結
Alexander 的核心主張：patterns 不是獨立的技巧，而是一個語言——它們相互連結，組合成比任何單一 pattern 更豐富的表達能力。
轉移到軟體
Kent Beck 與 Ward Cunningham 在 1987 年的 OOPSLA 大會上，把 Alexander 的 pattern 格式應用到 Smalltalk 物件導向設計，開創了軟體 pattern 的傳統。
Gang of Four（1994）：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 出版《Design Patterns: Elements of Reusable Object-Oriented Software》，定義 23 個 OOP patterns（Creational / Structural / Behavioral 三大類）。它把「Observer pattern」「Strategy pattern」「Factory pattern」這些名詞帶進軟體工程的日常詞彙。更多資訊：refactoring.guru/design-patterns/history
POSA（Pattern-Oriented Software Architecture）系列：把 patterns 擴展到系統架構層面——Layers、MVC、Pipes & Filters、Broker 等。O’Reilly 出版的系列叢書（Volume 1-5）涵蓋從單體到分散式系統的架構 patterns。
DDD Patterns（Eric Evans, 2003）：Domain-Driven Design 藍皮書定義了一套專門針對複雜業務領域的 patterns——它們是這條設計流程最直接相關的 pattern 集合：
| Pattern | 說明 | 在流程中的角色 |
|---|---|---|
| Aggregate | 一致性邊界：所有對其內部物件的修改都必須透過 Aggregate Root | Event Storming → Event Sourcing 的核心對應 |
| Repository | 把 Aggregate 的持久化細節隱藏在集合抽象後面 | Event Store 的介面設計 |
| Domain Event | 領域裡已發生的事的不可變記錄 | Event Sourcing 的基本單元 |
| Value Object | 沒有識別 ID、只看值的物件（Money、Address、DateRange） | 減少 Aggregate 內部複雜度 |
| Domain Service | 跨越多個 Aggregate 的操作，無法自然放進任何單一 Aggregate | 跨 Aggregate 的業務規則 |
| Anti-Corruption Layer（ACL） | 在 Bounded Contexts 之間轉換語言，防止外部模型污染內部模型 | Context Map 的邊界保護 |
| Bounded Context | 一個統一語言有效的邊界——邊界內詞彙的含義一致 | Event Storming 識別的邊界 |
如何為自己的領域寫 Pattern
DDD patterns 和 GoF patterns 是已知的通用 patterns；但每個領域和每個團隊，在解決反覆出現的問題時，都會形成自己的局部 patterns。把這些局部解法命名、寫下來，就是「為領域寫 Pattern」。
模板：
## Pattern 名稱
**情境**：在什麼情況下會遇到這個問題？
（例：「當一個業務流程涉及多個 Aggregate，且需要確保最終一致性時」）
**Forces**：
- 業務要求強一致（不能有中間狀態）
- 分散式系統中的強一致代價很高
- 單一 Aggregate 的邊界又不允許把所有資料放進去
**解法**：
（例：用 Saga / Process Manager——一個長生命週期的物件，
監聽 Domain Events，依順序發出 Commands，補償失敗步驟）
**後果**：
- ✓ 保持各 Aggregate 的邊界清晰
- ✓ 失敗可以補償
- ✗ 最終一致性，有短暫的中間狀態
- ✗ Saga 本身成為狀態管理的複雜點
**關聯 Patterns**：Aggregate、Domain Event、Anti-Corruption Layer寫 Pattern 的觸發時機：
- 遇到同一類問題第二次時
- 做 code review 時說了「這裡應該用 XXX 模式處理」但沒有文件
- Event Storming 之後發現某一類 Hotspot 反覆出現
- 新團隊成員來了，需要解釋「我們為什麼這樣設計」
Pattern Catalog 作為 AI 的設計詞彙
Pattern Catalog 對 AI coding agent 的價值是結構性的：當 pattern 有明確的名稱、情境、forces、解法，AI agent 可以把「識別問題屬於哪個 pattern」和「套用 pattern 的解法」拆成兩個有根據的步驟，而不是每次憑感覺生成代碼。
在 CLAUDE.md 或 spec 的 design decisions 段落引用 Pattern Catalog：
## Design Decisions
採用 **Saga Pattern**（見 pattern-catalog/saga.md）處理訂單→支付→庫存扣減的跨 Aggregate 流程：
- 觸發：OrderCreated event
- Step 1：向 Payment Aggregate 發 CapturePayment command
- Step 2（成功）：向 Inventory 發 DeductStock command
- Step 2（失敗）：發 OrderCancellation command 補償AI agent 讀到這份說明後，它知道這個問題已被分類，解法有明確的 forces 和後果，不需要重新發明。
Pattern Language vs. 一次性設計決策
Pattern Language 的意義在於語言——它是可被多人說、可被 AI 引用、可被新成員快速學會的詞彙系統。單一設計決策只服務這次，Pattern Language 服務未來所有類似情境。
建立 Pattern Language 的實用起點：
- 在 repo 裡建立
docs/patterns/目錄 - 每個 pattern 一個 Markdown 文件，用統一模板
- 在 CLAUDE.md 裡指引 AI：「設計決策優先從 docs/patterns/ 選用已有 pattern；新 pattern 請先在此目錄建立文件再實作」
- Code review 時用 pattern 名稱溝通（「這裡應該用 ACL」而不是「這裡要加一層轉換」）
方法論主張（未量化）：「Pattern Language 降低溝通成本、提升新成員學習效率」是軟體工程界廣泛認可的主張，但「具體降低多少」沒有針對個別團隊的數字。
延伸
- Event Storming 識別的 Aggregates 如何對應 DDD Patterns → Event Storming：協作式領域探索
- 後端的 Aggregate / Repository / Domain Event 設計 → Event Sourcing + CQRS：後端落地
- 實戰中 Pattern Catalog 的建立與使用 → 完整流程實戰：電商訂單系統走一遍
- 回到全景 → Event Storming + Event Sourcing + Pattern Language 專欄首頁