DDD—上下文映射图

一个项目的上下文映射图（Context Map）可以用两种方式表示，
（1）比较容易的一种是画一个简单的框图来表示两个或多个限界上下文之间的映射关系。该框图表示了不同的限界上下文在解决方案空间中是如何通过集成相互关联的。

（2）另一种更详细的方式通过限界上下文集成的源代码实现来表示。

1、上下文映射图为什么重要

在开始采用DDD时，首先应该为你当前的项目绘制一个上下文映射图，其中应该包含你项目中当前的限界上下文和它们之间的集成关系。下图表示一个抽象的上下文映射图，后文将不断地向里面添加细节内容。

团队成员意识到安全、用户和权限并不属于协作上下文，需要将这些概念从核心域中分离出来，是这些概念只有在得到同意的时候才能进入核心域。

在对子域进行了分析，或对问题空间进行了评估之后，团队所绘制的上下文映射图如图所示，从一个限界上下文中分离出了两个子域。由于子域和限界上下文最好保持一对一的关系，我们应该将原来的协作上下文分离成两个限界上下文。

当下一个ProjectOvation项目启动时，团队将使用这个新的核心域——敏捷项目管理上下文来增强已有的上下文映射图，如图所示。

上图是放大后的上下文映射图，下游系统的边界对象采用同步的方式向上游系统获取到资源。当获取到远程数据模型数据之后，边界对象取出所需数据，再将其翻译成适当的值对象实例。

在图中我们看到，对于身份与访问上下文的领域事件，系统将以URI的方式向外发布事件通知。这种功能是通过NotificationResource提供的，它向外发布REST资源。这里的通知资源是一组被发布的领域事件。对于消费方来说，每个事件总是可用的。消费方应该避免对事件的重复消费。

一个自定义的媒体类型表明客户可以请求两种资源：

可以看出，这里的URI是全新的，并且是稳定的，因此它不会改变。无论当前的通知日志中包含了什么样的内容，该URI都会将其发布。

事实上，ProjectOvation团队并不打算全盘使用REST。比如，他们目前正与CollabOvation团队协商是否可以使用消息机制，例如rabbitMQ。但就目前而言，它们和身份与访问上下文的集成依然是基于REST的。

现在，让我们忽略技术细节，看看映射图中各个交互对象所扮演的角色。如图表示集成过程的序列图：

此时，ProjectOvation团队还不清楚采用哪种方式与CollabOvation进行集成。在讨论了客户方-供应方关系后，它们得到了下图：

敏捷项目管理上下文可以使用第二个防腐层来处理与协作上下文之间的集成。事实上CollaborationAdapter并不是单个，此处只是一个占位符，表示有多个适配器。

敏捷项目上下文在本地有DiscussionService和SchedulingService，它们是领域服务，用于管理协作系统中的讨论和日历条目。

以上的例子已经展示了上下文映射图的某些细节。

对于一个非常详细的上下文映射图，我们很有可能无法对其进行实时更新。保持简单性和敏捷性，拒绝繁文缛节，这样我们创建的上下文映射图将对项目起推动作用，而不是阻碍作用。