（6）应用边界的识别

对应用边界的识别，就是从技术维度考量限界上下文，包括考虑系统的质量属性、模块的复用性、对需求变化的应对和处理遗留系统的集成等。

我们与客户决策层一起确认了报表功能的需求，客户希望统计报表能够准确及时地展现历史和当前的人才供需情况。统计报表功能直接影响了目标系统的愿景，是系统的核心功能之一，需要花费更多精力来明确设计方案。通观与统计报表有关的业务服务，除了与职能部门管理工作有关的统计日报、周报和月报，报表的统计结果实际上为集团领导进行决策提供了数据层面的辅助支持。要提供准确的数据统计，就需要对市场需求、客户需求、项目、员工、储备人才、招聘活动等数据做整体分析，也就需要整个系统核心限界上下文的数据支持。倘若EAS的每个限界上下文并未采用微服务这种零共享架构，整个系统的数据就可以存储在一个数据库中，无须进行数据的采集和同步即可支持统计分析。另一种选择是引入数据仓库，采用诸如ETL等形式完成对各个生产数据库和日志文件的采集，经过统一的数据治理后为统计分析提供数据支持。

在分析工作边界时，我考虑到报表上下文与其他限界上下文之间存在强依赖关系，无法支持并行开发，因而将该上下文的功能按照业务相关性分配给其他限界上下文。如今，通过技术分析得知，虽然依赖仍然存在，但该上下文更多地体现了“决策分析”的特定领域。最终，我决定保留该限界上下文，并将其更名为决策分析上下文。

在考虑通知上下文的实现时，基于之前确定的系统上下文，EAS系统要与集团现有的OA系统集成。我们了解了OA系统公开的服务接口，发现这些接口已经提供了多种消息通知功能，包括站内消息、邮件通知和短消息通知，没有必要在EAS系统中重复开发通知功能。那么，通知上下文是否就没有存在的必要呢？一旦去掉通知上下文，与OA系统集成的功能又该放在哪里？领域驱动设计建议将这种与第三方服务集成的功能放在防腐层，可EAS系统中的多个限界上下文都需要调用该功能，会形成防腐层的重复建设。为了满足功能的复用性，可以为它单独创建一个限界上下文。为了说明其意图，将它更名为OA集成上下文。

最终，得到图20-41所示的限界上下文。

3．上下文映射

确定了目标系统的限界上下文之后，即可通过业务服务获得的服务序列图确定限界上下文之间的协作关系，从而确定上下文映射模式，设计出服务契约。

（1）创建市场需求

创建市场需求业务服务属于订单上下文，它拥有的领域知识已经足以满足该业务服务的需求，无须求助于其他的限界上下文，因此在本业务服务中，没有上下文映射。服务序列图如图20-42所示。

虽然创建市场需求没有多个限界上下文参与协作，但为其绘制服务序列图仍有必要，因为可以通过它驱动出创建市场需求的服务契约。

（2）归档合同

归档合同业务服务属于合同上下文，具备合同相关的领域知识，但不具备上传文件的业务能力，需要求助于文件共享上下文，服务序列图如图20-43所示。

文件共享上下文作为支撑子领域的限界上下文，主要提供了文件上传与下载的功能。它具有的领域知识还包括针对不同类型的文档维护了服务器文件存储的路径映射，故而参与协作的是北向网关的应用服务。形成的上下文映射图如图20-44所示。

（3）添加项目成员

添加项目成员业务服务属于项目上下文，拥有与项目相关的所有领域知识和业务能力，但并不具备发送通知的业务能力，也不知道该如何将当前项目的信息添加到员工的项目经验中，因此需要分别求助于OA集成上下文和员工上下文。服务序列图如图20-45所示。

OA集成上下文要实现的功能都与通知有关。无论是短信通知、邮件通知还是站内通知，都没有副作用，且允许以异步形式调用，适合使用事件的调用机制，因而为其选择发布者/订阅者模式。选择该模式既可以解除OA集成上下文与大多数限界上下文之间的耦合，又能较好地保证EAS系统的响应速度，减轻主应用服务器的压力。不足是需要增加一台部署消息队列的服务器，并在一定程度增加了架构的复杂度。如图20-45所示，项目管理者在添加了项目成员之后，会向事件总线发布TeamMemberAdded应用事件，并由OA集成上下文的事件订阅者订阅该事件。形成的上下文映射图如图20-46所示。

为主要的业务服务绘制服务序列图，深层次地思考各个限界上下文如何参与到每个业务服务、它们又该如何协作、应该采用什么样的上下文映射模式，就可以得到整个EAS系统的上下文映射图，如图20-47所示。

上下文映射图不仅说明了限界上下文之间的协作关系、彼此间采用的团队协作模式，也可以作为服务契约设计的参考和补充。