7.有界上下文映射

前面提到多次有界上下文，上下文可以理解为理想中已经划分好了的微服务（也可能是DDD分层代码中的一个domain层的实现，这个后面在战术模式中会提到）理想状况下一个上下文会完整的包含一个领域模型，不会和其他上下文共享，但不总是如此。创建一个上下文要专注于当前的问题区域，仅专注于要直接集成的上下文，具体实现在后面会讲，这里只是对上下文之间的管理关系做介绍。

1.上下文映射的重要性

1. 保持完整性：有助于团队理解服务之间的关联关系，避免职责边界模糊不清，使得代码更灵活不会出现连锁反应。

2. 解决计划的基础：会凸显混乱的部分和核心领域，可以帮助团队定位首先要解决的区域，提供项目成功几率，还是说关注核心领域。

3. 理解所有权和职责

4. 揭示业务工作流中的混乱区域。

2. 有界上下文的映射关系

image-20220803065047947.png

1. 防止损坏层 下图的防止损坏层仅仅负责翻译转换，商务服务内并不直接引用订单内部的模型，而是增加一层转换代码，这个转换代码可以和商务代码在一个仓库。如果商务服务代码比较混乱不希望在增加代码时，可以起一个新的服务内部引用商务服务接口，逐步替换。这种转换在DDD分层代码中也非常见，后面介绍代码风格的时候会发现每一层都是通过assember层实现不同层的dto或者entity转换的。

image-20220803071202982.png

2. 共享内核

两个服务共用了一个模型，共享模型代码，优点是避免了重复开发，但是缺点是引入耦合性。实际中没有接触到类似的情景， 即使是下图也会在不同的上下文分别创建自己的模型，因为随着业务发展员工模型在工资表上下文或者人事上下文中的关注点 以及属性是不一样的，一个团队的改动可能会导致影响另一个团队。所以除非两个团队负责的微服务有大量的交叉引用很多极其相似的模型，才会这样设计。

image-20220803072913089.png

3. 开放宿主服务

比如对于订单服务来说，调用方很多，比如商务服务、采购服务，每个服务都需要拿到订单数据转换成自己需要的订单数据，有些服务可能只需要一些特定的字段就可以了。订单服务可以开放几个接口比如精简的订单信息、订单详情。甚至专门为调用方开发特定的订单信息接口（这个看具体场景，没有足够充分理由的时候订单系统可能不会支持）。

4. 分道扬镳

系统集成复杂度过高，不相互集成。比如存在订单系统和管理系统，如果管理系统里面集成了订单系统的话，比如我在管理系统查看某个人的信息，是可以获取到对应的订单信息的，但是集成复杂度高，只能把订单系统做一个单独的tab，查询到人以后
然后再根据user_id在订单系统搜索。

5. 合作关系

多个微服务都朝着同一个目标推进，这个一般说的是微服务之间是平级的，依赖是双向的 比如由于历史原因，A服务中有些功能其实应该由B服务实现，需要将这部分功能进行迁移。

6. 上下游关系

这里下游依赖上游提供的数据或者行为（上下游概念不一定总是一致，比如我还见过根据请求数据流向定义的，把请求数据流看成水流，这样和这里定义就是相反的）

• 顾客-供应商关系

这个就是常见的内部微服务之间的依赖关系，顾客指的是下游、供应商是上游，这里强调上游的改动要充分被下游理解，防止上游的改动破坏项目整体性。

• 遵从

下游只能遵循上游提出的规则，这个一般是集成的外部系统，比如支付，也可能是公司内部偏底层的服务，他们一般不会单独为某个下游做改变，这种情况下只能遵从上游的模型来简化集成。