🎯 什麼情境該想到我
當你「兩個上下文的團隊命運綁在一起——一邊失敗另一邊也跟著失敗，功能必須協同規劃、一起交付」的時候。你需要一種雙向承諾的緊密協作關係。
⚙️ 怎麼用（步驟 / 公式）
意圖：兩個上下文的團隊建立對等的合作關係，因為彼此成敗與共。雙方承諾協同進行功能規劃、整合節奏與交付，共同對整合成功負責。
做法要點：
- 確認兩上下文確實高度相互依賴、成敗綁在一起，才適用此模式。
- 建立共同的規劃機制：一起排功能、對齊介面與交付時程。
- 協調整合節奏，讓雙方的變更同步演進、彼此不拖後腿。
- 建立持續溝通與共同的整合測試，維持這份雙向承諾。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 需要兩隊有良好關係與高頻溝通；團隊間信任不足或無法密切協調時撐不起來。
- 協調成本高，只在「真的成敗與共」時才值得；關係沒那麼緊密時用客戶-供應商即可。
- 與共享核心常相伴，但合作關係強調的是「共同規劃與交付的承諾」，不必然共用同一份程式碼。
🔗 相關工具
- 共享核心 Shared Kernel（常相伴的緊密耦合形式）
- 客戶-供應商 Customer-Supplier（較不對等、上下游式的替代關係）
- 上下文對應 Context Map（把合作關係標在地圖上）
- 領域驅動設計