原则： 各司其职 权责分明
从组织角度看：
预防一个团队 权利膨胀 团队势力扩大到整个组织
从团队角度看：
避免自己权利被压缩，导致话语权减小
如何平衡？
满足合理分配职责的前提下，谨慎地确保每个限界上下文的粒度。
领域驱动设计根据团队协作的方式与紧密程度，定义了五种团队协作模式：
合作关系：
合作得越多，就意味着依赖越多：二者可能存在强耦合关系，甚至是糟糕的双向依赖
限界上下文的“合作关系”其实是一种“反模式”，罪魁祸首是因为职责分配的不当，解决的办法通常有三种：
1 拆分的理由较为牵强，不应拆开 应该合在一起
2 找到产生依赖的职责 重新审视 造成多余依赖的 职责的正确位置
3 找到 双向依赖的 原因 将造成双向依赖的 职责 从 限界上下文中 独立出来 建立单独的 限界上下文 其他上下文依赖 这个单独的上下文（共享内核）
如下图示例
双向依赖：
拆分出单独的元数据：
共享内核：
共享内核往往被用来解决合作关系引入的问题。
共享内核是通过上下文映射识别出来的，通过它可以改进设计质量，弥补之前识别限界上下文的不足。
主要的驱动力就是“避免重复”，即 DRY（Don't Repeat Yourself）原则的体现。
作业与指令功能放在运输、货站或堆场都不合理，这时就是运用“共享内核”的时机。
为了避免重复，也为了避免不必要的依赖，可以提取出作业上下文。
ps: xml配置文件 都放在 应用层 或 实现层 都不合理 此时 可以独立出module 专门存放配置文件 避免 不必要的依赖
共享内核不能像其他设计部分那样自由更改，在做决定时需要与另一个团队协商
对共享内核进行修改时，需要充分评估这种修改可能带来的影响。（评估出 对下游造成的影响）
客户方-供应方开发:
上游需要考虑：
如何针对不同的领域需求建立统一的抽象：通用性建设
遵奉者：
下游限界上下文对上游限界上下文模型的追随：
-
可以直接重用上游上下文的模型（好的）
-
减少了两个限界上下文之间模型的转换成本（好的）
-
使得下游限界上下文对上游产生了模型上的强依赖（坏的）
分离方式：
两个限界上下文之间没有丝毫关系
促进它们独立发展，彼此不受影响。
