兩個概念之間的耦合與某些屬性有關。不論哪個屬性更改都會影響一起更改的內容。我們的有界上下文邊界劃分是一種押注，押注那些會一起改變的事情。

(如圖，可以按照形狀劃分界限，也可以按照顏色劃分邊界，或者按照在流程是否一起使用劃分)

在前期設計中需要平衡過度設計和過少設計：我們希望在做出艱難/昂貴的更改設計選擇之前就早日反饋... ...但是我們不想基於困難的/昂貴的有缺陷設計開始構建發現有缺陷時進行更改。（不能在敏捷實踐過程發現有嚴重方向性戰略性路線問題時才開始修改，南轅北轍了）

我們希望儘早獲得設計反饋，以驗證我們的選擇。但是我們需要牢記獲取反饋的成本。示例：花費15人日的時間編碼等同於我們在2個小時的EventStorming中學到的東西。

我稱此（通過敏捷實踐編碼）為蠻力的領域發現。您只需繼續編碼。每次沒有意義時，您都回去尋求澄清。有時效率會非常低下，而有時實際上是用程式碼編寫某些東西進行編譯可能是最好的方法。(banq注：這是兔子和烏龜的故事，兔子跑不過烏龜不是因為兔子懶，而是兔子會瞎折騰，一會向比賽方向快速跑，一會兒反向快速跑，最後還是跑不過有堅定信仰但行動遲緩的烏龜)