好的服務邊界就一句話：強內聚 + 鬆耦合 + 穩定。內聚是「一起變的東西住一起」，耦合是「改 A 要不要動 B」。泛泛喊「要解耦」沒用——得有能分析耦合的具體詞彙。
🧠 Core Ideas
TIP
內聚 (Cohesion)：一起變動的程式碼，住在一起——散落多個服務，每次發佈都要協調多方上線，又慢又危險。耦合 (Coupling)：改一個部分會不會逼另一個也改。Parnas 的洞見——模組間的「連接」其實是它們對彼此的假設；假設愈少，愈能獨立變更。
- 資訊隱藏：把細節藏在邊界內，帶來平行開發、可理解性、可獨立變更三個好處。
- Constantine 定律：內聚強、耦合弱 → 結構穩定；穩定邊界是獨立部署的前提。
⚖️ 耦合的四種型態（從鬆到緊）
1. 領域耦合（Domain Coupling）— 最鬆
- A 因為需要 B 的功能而呼叫 B，微服務裡幾乎不可避免。原則：只分享絕對必要的資訊、傳最少資料。
- 警訊：依賴一大堆下游，可能代表這個服務做太多。
- 附帶的時間耦合：同步呼叫要兩者同時在線 → 用非同步（message broker）化解。
2. 穿透耦合（Pass-Through Coupling）
- A 把資料傳給 B、只為了讓 B 再傳給 C；於是 A 連 C 的結構需求都得知道，C 一改連鎖波及 A、B。
- 化解：A 直接呼叫 C／把建構下游請求的邏輯封裝進 B／把資料當不透明 blob 通過 B。
3. 共用耦合（Common Coupling）— 最常見的共享資料庫
- 兩個以上服務共享同一份資料（多半是共享 DB）。結構一改所有消費者受影響、資料難演進、隱含資源競爭。
- 靜態參考資料（國家清單、貨幣代碼）尚可；共寫共讀很危險。
- 正解：讓單一服務當狀態的唯一真相來源，其他服務用「請求」提出變更，由它依有限狀態機決定接受或拒絕。
4. 內容耦合（Content Coupling）— 病態耦合，最糟
- 上游直接深入下游內部改它的狀態（最常見＝直接寫對方資料庫）。
- 比共用耦合更糟：失去所有權邊界、DB 結構變成隱性契約、資訊隱藏完全失效。
⚖️ Hard Parts 的視角：靜態 vs 動態耦合
Architecture Quantum 與兩種耦合
- Architecture quantum：一個具高功能內聚、高靜態耦合、同步動態耦合的獨立可部署產物。
- 靜態耦合＝服務如何被「連接 (wired)」（作業系統、框架、程式庫、契約、共享 DB）——依賴同一 DB 就不算獨立 quanta。
- 動態耦合＝執行期如何「呼叫 (call)」：同步（呼叫端被 block、暫時耦合）vs 非同步（各自獨立運作）。
- WARNING：微服務若 UI 與後端用同步緊耦合，整個架構可能退化成單一 quantum——用 micro frontend 可避免。
🔑 Takeaways
- 好邊界 = 強內聚 + 鬆耦合 + 穩定；Parnas：連接就是假設，假設愈少愈鬆。
- 耦合光譜：領域 < 穿透 < 共用 < 內容（病態）；共享資料庫是最常見的坑。
- 用「唯一真相來源 + 請求變更」取代共寫；用非同步化解時間耦合。
- Hard Parts 補上靜態 vs 動態兩軸——靜態看怎麼接線、動態看怎麼呼叫。
No notes yet — jot your takeaways or Q&A here.