上下文映射的团队协作模式

原则： 各司其职 权责分明

从组织角度看：

预防一个团队 权利膨胀 团队势力扩大到整个组织

从团队角度看：

避免自己权利被压缩，导致话语权减小

如何平衡？

满足合理分配职责的前提下，谨慎地确保每个限界上下文的粒度。

 

领域驱动设计根据团队协作的方式与紧密程度，定义了五种团队协作模式：

 

合作关系：

合作得越多，就意味着依赖越多：二者可能存在强耦合关系，甚至是糟糕的双向依赖

 

限界上下文的“合作关系”其实是一种“反模式”，罪魁祸首是因为职责分配的不当，解决的办法通常有三种：

1 拆分的理由较为牵强，不应拆开 应该合在一起

2 找到产生依赖的职责 重新审视 造成多余依赖的 职责的正确位置

3 找到 双向依赖的 原因 将造成双向依赖的 职责 从 限界上下文中 独立出来 建立单独的 限界上下文 其他上下文依赖 这个单独的上下文（共享内核）

 

如下图示例

 

双向依赖：

​

 

拆分出单独的元数据：

​

 

共享内核：

共享内核往往被用来解决合作关系引入的问题。

共享内核是通过上下文映射识别出来的，通过它可以改进设计质量，弥补之前识别限界上下文的不足。

 

主要的驱动力就是“避免重复”，即 DRY（Don't Repeat Yourself）原则的体现。

作业与指令功能放在运输、货站或堆场都不合理，这时就是运用“共享内核”的时机。

为了避免重复，也为了避免不必要的依赖，可以提取出作业上下文。

 

ps: xml配置文件 都放在 应用层 或 实现层 都不合理 此时 可以独立出module 专门存放配置文件 避免 不必要的依赖

 

共享内核不能像其他设计部分那样自由更改，在做决定时需要与另一个团队协商

对共享内核进行修改时，需要充分评估这种修改可能带来的影响。（评估出 对下游造成的影响）

 

客户方-供应方开发:

上游需要考虑：

如何针对不同的领域需求建立统一的抽象：通用性建设

 

遵奉者：

 

下游限界上下文对上游限界上下文模型的追随：

 

• 可以直接重用上游上下文的模型（好的）

• 减少了两个限界上下文之间模型的转换成本（好的）

• 使得下游限界上下文对上游产生了模型上的强依赖（坏的）

 

 

分离方式：

两个限界上下文之间没有丝毫关系

促进它们独立发展，彼此不受影响。