两个概念之间的耦合与某些属性有关。不论哪个属性更改都会影响一起更改的内容。我们的有界上下文边界划分是一种押注，押注那些会一起改变的事情。
(如图，可以按照形状划分界限，也可以按照颜色划分边界，或者按照在流程是否一起使用划分)
在前期设计中需要平衡过度设计和过少设计：我们希望在做出艰难/昂贵的更改设计选择之前就早日反馈... ...但是我们不想基于困难的/昂贵的有缺陷设计开始构建发现有缺陷时进行更改。（不能在敏捷实践过程发现有严重方向性战略性路线问题时才开始修改，南辕北辙了）
我们希望尽早获得设计反馈，以验证我们的选择。但是我们需要牢记获取反馈的成本。示例：花费15人日的时间编码等同于我们在2个小时的EventStorming中学到的东西。
我称此（通过敏捷实践编码）为蛮力的领域发现。您只需继续编码。每次没有意义时，您都回去寻求澄清。有时效率会非常低下，而有时实际上是用代码编写某些东西进行编译可能是最好的方法。(banq注：这是兔子和乌龟的故事，兔子跑不过乌龟不是因为兔子懒，而是兔子会瞎折腾，一会向比赛方向快速跑，一会儿反向快速跑，最后还是跑不过有坚定信仰但行动迟缓的乌龟)