🎯 什麼情境該想到我
當你要決定「一個微服務該多大、邊界畫在哪、從單體怎麼拆」時。
⚙️ 怎麼用
- 按業務能力/限界上下文切（見 工具-限界上下文），不按技術分層切。
- 檢驗好邊界：服務能獨立變更、獨立部署嗎？若一個改動總要同時改好幾個服務 → 邊界錯了。
- 每個服務擁有自己的資料：不共用資料庫，透過 API/事件互動（避免隱性耦合）。
- 服務間別太聊天：若兩服務呼叫極頻繁，可能該合併——高內聚該在同一服務內。
- 演進式拆分：從單體開始，沿著真實痛點與清楚的接縫逐步剝離（見 工具-架構隨業務規模演進）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 拆太細（nano-service）會讓網路呼叫、分散式事務、運維成本爆炸；寧可先粗再細。
🔗 相關工具
- 工具-限界上下文 —— DDD 版的同一件事，補上「怎麼從業務語言找出邊界」的方法
- 工具-康威定律 —— 現實限制，邊界畫得再漂亮，跟組織結構對不上就維持不住
- 工具-服務架構的演進與拆分 —— 姊妹卡，這張談邊界怎麼畫，它談什麼時候該拆、拆到什麼程度