該用什麼切服務邊界？首選是業務領域。DDD 給的工具正是把領域對應到服務最有效的一組概念：通用語言、聚合、界限上下文。切邊界的目標不變——強內聚、鬆耦合、穩定。
🧠 Core Ideas
TIP
界限上下文 (Bounded Context) 是有明確責任的較大邊界，隱藏內部實作、對外只暴露該暴露的。它由一或多個聚合 (Aggregate) 組成。起步時「一個界限上下文 = 一個微服務」，熟悉後再沿聚合邊界拆細。
- 通用語言：程式碼用領域使用者真正在講的詞（別讓 PM 說 haircut、程式碼寫抽象的 arrangement，每次溝通都要翻譯）。
- 聚合：真實領域概念（Order、Invoice），有生命週期、常實作成狀態機、由單一微服務管理；外部請求變更時聚合有權拒絕，理想是讓非法狀態轉換根本不可能。
⚖️ 領域之外的分解驅動因素
不只看領域
- 變動性：把最常改的部分抽出，縮短上市時間。
- 資料：PII / 信用卡（PCI）要隔離——把完整卡處理放「紅區」稽核，其餘在「綠區」，卡資料絕不流到綠區。
- 技術：不同部分需不同執行環境；但別退化成「按技術切水平三層」。
- 組織：康威定律已定調——要做垂直切片（業務功能端到端），不要水平切片。
套娃結構與過早分解
- 界限上下文內可再切更細的上下文（倉庫可再分揀貨/庫存/進貨），且可對外隱藏（對外仍是單一 Warehouse）。
- 過早分解的危險：SnapCI 一開始就拆多個微服務，幾個月後發現邊界全錯，合回單體、又花一年重切。從既有單體拆出微服務，通常比一開始就用微服務容易。
⚖️ 建模與常見警訊
Event Storming（事件風暴）
- Brandolini 的協作工作坊：讓技術與非技術利害關係人一起建模，避免架構師關門造車。
- 四步：找領域事件（橘）→ 找指令（藍，此階段技術人該聽而非主導）→ 辨識聚合（黃）→ 聚合分群成界限上下文（常貼合組織）。
常見警訊
- CRUD 薄殼：微服務若只是資料庫 CRUD 的薄殼，代表內聚弱、耦合緊，屬於它的邏輯被擠到別處。
- 內容耦合：一旦讓外部直接存取你的 DB，DB 就成對外契約——見 耦合與內聚。
- 分層：微服務內部分層 OK；用「層」當服務/團隊的所有權邊界不行。
- IMPORTANT：微服務不是目的——不同的目的導致不同的驅動因素，須為解決真正的問題而拆。
🔑 Takeaways
- 首選按業務領域切；DDD 的通用語言 / 聚合 / 界限上下文是最有效的對應工具。
- 起步「一個界限上下文一個服務」，再沿聚合拆細；過早分解代價高。
- 領域之外還有變動性、資料、技術、組織四個驅動因素；一律垂直切片。
- 警惕 CRUD 薄殼與內容耦合；記得微服務是手段不是目的。
No notes yet — jot your takeaways or Q&A here.