🎯 什麼情境該想到我
當你在猶豫「現在就該上分散式/微服務/複雜中間件嗎，還是先簡單做」時。
⚙️ 怎麼用
- 在痛點真的出現時才演進：DB 撐不住才分庫分表、單體真的擋路才拆服務。別為「想像中的未來規模」預先過度設計。
- 每次升級對準一個真實瓶頸：先量測、確認瓶頸，再針對它升級（呼應 工具-找出並管理約束點）。
- 保留演進空間，但不預先實作：介面/邊界留好（工具-限界上下文），讓未來好改，但現在保持簡單。
- 把共通難題沉澱成平台/中間件：等同類需求重複出現，再抽象共用，而非一開始就造框架。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 兩個極端都要避免：過早複雜化（YAGNI）與拖到系統崩潰才動。用「真實痛點 + 數據」判斷時機。
🔗 相關工具
- 工具-服務架構的演進與拆分 —— 具體到微服務這一題，什麼規模該拆、怎麼拆
- 工具-管理複雜度 —— 判斷準則，提早上複雜架構等於提早付複雜度的帳
- 工具-沒有銀彈 —— 同一種清醒，新架構不會讓問題消失，只會換一批問題