🎯 什麼情境該想到我
當你「兩個上下文是明確的上游供給、下游消費關係，而下游的需求該被上游正式納入規劃」的時候。你想把這種依賴變成有約定、可協商的關係，而不是下游單方面被動承受。
⚙️ 怎麼用（步驟 / 公式）
意圖：確立上游（供應商）與下游（客戶）的關係，讓下游的需求被上游納入規劃與優先序，並以自動化測試把介面約定固定下來，讓上游能安心變更。
做法要點：
- 明確指定誰是上游供應商、誰是下游客戶，以及流動方向。
- 建立協商機制：下游把需求提入上游的規劃流程，雙方一起排優先序與時程。
- 以下游驅動的驗收測試把介面約定固化；上游改動要先通過這些測試。
- 把測試納入上游的持續整合，讓上游能在不驚動下游的前提下自由演進內部。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 前提是上游團隊願意且有動機服務下游；若上游根本不理下游，這模式撐不起來（此時下游多半只能追隨者或建防腐層）。
- 一個上游有多個下游時，需求會互相衝突，優先序協調成本上升。
- 過度綁定下游的驗收測試也可能拖慢上游，要平衡「約定」與「上游自主」。
🔗 相關工具
- 追隨者 Conformist（上游不配合時，下游只能順從的退化情形）
- 防腐層 Anticorruption Layer（下游自保、隔離上游變動的手段）
- 開放主機服務 Open Host Service（上游服務多個下游時的做法）
- 領域驅動設計