一、什么是上下文映射？

我们在识别限界上下文后，通常会划分出来多个限界上下文，那么这些限界上下文之间的协作关系，我们称之为上下文映射。

二、上下文映射有哪些模式？

从技术和团队合作两个角度出发，可以归纳为通信集成模式和团队协作模式，其中通信集成模式从技术实现角度讨论了限界上下文之间的通信集成方式，关注点主要体现在对限界上下文边界的定义和保护，确定模型之间的协作关系以及通信集成的机制与协议；而团队协议模式将限界上下文的边界视为领域特征团队的工作边界，限界上下文之间的协作实际上展现了团队之间的协作方式。

1、通信集成模式

通信集成模式主要体现了限界上下文之间的通信方式，通常情况下，都会用到开放主机服务、防腐层、发布语言以及共享内核这几种。

① 开放主机服务（OHS：Open Host Service）

如果限界上下文以微服务的形式呈现的话，开放主机服务就是微服务对外暴露的API接口，设计开放主机服务包括定义通信的方式、通信地址以及请求和响应参数，目前比较流行通信方式包括REST和RPC两种。

② 防腐层（ACL：Anti Corruption Layer）

上游限界上下文通过开放主机服务对外暴露服务接口，对于下游限界上下文，通常不会直接在业务流程中去调用上游接口，这会让下游限界上下文与上游限界上下文强耦合，如果上游接口有变动，下游限界上下文也要跟着变动，通常的做法是引入一层防腐层，也就是适配层，隔离下游限界上下文的业务与下游接口，从而方便下游替换或者变动上游接口。

如上图所示，XXRemoteService就是下游限界上下中的防腐层。

③ 发布语言

无论是上游的OHS还是下游的ACL，我们最好对请求和响应参数进行封装，形成发布语言，避免参数过于分散难以理解。一般情况下，如果在同一个部门采用相同的开发语言，比如Java，那么一般都会把这些参数提取到接口包，方便下游限界上下文直接引入，无需再定义这些参数。

④ 共享内核

如果多个限界上下文存在相同的业务逻辑，比如发送邮件，那么通常会把发送邮件这样的功能提取到通用限界上下文，那么通用限界上下文除了可以对外开放OHS之外，还可以以包的方式直接被下游限界上下文引入使用，从而变成多个限界上下文的共享内核。在实际开发中，这样的形式通常体现在工具包中（xxx-common），我们把工具类统一放到工具包中，供其他模块直接引入使用。

2、团队协作模式

团队协作模式指的是限界上下文之间的协作模式，常见的协作模式包括：客户方/供应方、合作者、发布者/订阅者、分离方式、尊奉者等。

① 客户方/供应方

客户方/供应方这种协作方式指的是下游限界上下文直接通过API调用上游限界上下文，比如在电商平台中，订单上下文调用物流上下文提交物流信息，对于限界上下文数量比较少的平台，这种协作方式比较简单，但是如果数量比较多，限界上下文之间相互调用，当其中一个限界上下文宕机了容易引发雪崩，而且调用混乱也增加治理难度。

② 发布者/订阅者

如果说客户方/供应方是强耦合的协作关系，那么发布者/订阅者将打破这种关系，通过引入消息中间件让限界上下文之间解耦，比如在电商平台中，订单上下文并不会直接调用物流上下文提交物流信息，而是将创建物流信息通过消息的信息发送给消息中间件，而物流上线文通过订阅消息中间件进行消费消息。

发布者/订阅者这种协作方式的缺点是需要引入消息中间件，加大了系统的复杂度。

③ 分离方式

分离方式是一种比较理想的协作方式，也是我个人应用比较多的一种协作方式，限界上下文之间不会直接发生关系，但是一个复杂系统中，限界上下文之间一定存在某种业务联系，那么怎么处理呢？通常会引入聚合上下文，如果将限界上下文映射为微服务的话，聚合上下文就是在微服务之上的聚合服务，通常用于业务逻辑，比如在电商平台中，用户下订单的操作由聚合服务来控制，也就是聚合服务调用订单上下文创建订单，然后再调用物流上下文创建物流信息。

④ 合作者

合作者模式指的是两个限界上下文之间同生共死，其实这是一种坏味道，如果出现这种情况，我们可以适当考虑将两个限界上下文合并为一个。

⑤ 尊奉者

无论是客户方/供应方和发布者/订阅者，都是有下游限界上下文提出需求，上游限界上下文实现需求的方式，而尊奉者协作方式则反过来，由上游限界上下文定义好接口，下游限界上下文再根据已有的接口来实现自己的需求，这种方式有点类似于系统调用第三方平台接口一样，比如调用第三方短信服务，则是根据对方的接口文档来实现功能。

但如果公司内部出现这种协作模式，则说明组织关系有点僵硬，需要由上层领导来打破这种协作方式，减少下游限界上下文适配成本。