🎯 什麼情境該想到我
當你「兩個上下文之間硬要整合，帶來的效益其實不值那個成本與耦合」的時候。你想明確地做出「不整合」的決定，讓兩邊各做各的，反而更清爽。
⚙️ 怎麼用（步驟 / 公式）
意圖：當兩個上下文之間沒有值得的整合效益時，明確決定「不整合」——讓它們完全各自獨立發展，藉此避免無謂的耦合與協調成本。
做法要點：
- 誠實評估兩上下文整合的實際效益，對照它帶來的耦合與協調成本。
- 若效益不足以抵過成本，明確、有意識地決定不做整合。
- 讓兩邊各自擁有獨立模型、獨立演進，必要時在更上層（如使用者端）各自呈現即可。
- 把這個「各行其道」的決定記在上下文對應上，避免日後有人又偷偷把它們接起來。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 若兩上下文其實真的需要協作（有實質共同流程），各行其道會造成功能斷裂與重複，不適用。
- 這是「有意識的取捨」，不是放任脫節；要把決定講清楚並記錄，否則會被誤解成疏漏。
- 需求會變，今天不值得整合不代表永遠；要保留日後重評的空間。
🔗 相關工具
- 共享核心 Shared Kernel（相反：高度耦合的共用選擇）
- 追隨者 Conformist（另一種降低整合成本、但仍整合的選擇）
- 上下文對應 Context Map（把「不整合」的決定明確標在地圖上）
- 領域驅動設計