20.3.3EAS的架构映射
通过对EAS展开全局分析，我们已经获得了EAS系统的价值需求和业务需求。接下来，我将延续全局分析阶段输出的这些成果，开展架构映射，获得遵循领域驱动架构风格的架构映射战略设计方案。
1．映射系统上下文
全局分析阶段确定了EAS的利益相关者。通过对目标系统的分析，可以得出参与系统上下文的用户包括：集团决策者、市场部、人力资源部、项目管理部、子公司、服务中心、财务、员工。
整个目标系统就是EAS系统。在确定系统范围时，系统的当前状态告诉我们：集团已有OA系统提供部门之间的流程协作与消息通知，它是EAS系统的伴生系统。系统的当前状态虽然还告知软件学院和招聘网站的简历会作为集团的人才储备库，却并未确认EAS系统是否需要和软件学院与招聘网站集成。通过招聘流程服务蓝图可以确知，这些简历信息需要招聘专员手工录入EAS系统，因此，EAS系统的伴生系统并不包含软件学院和招聘网站。客户合作流程服务蓝图中的内部支持者包含了薪资管理系统，调用它提供的服务接口可以获得员工薪资，以便财务进行财务核算，这说明薪资管理系统也是EAS系统的伴生系统。EAS系统的系统上下文如图20-27所示。
确定了系统上下文，就确定了EAS系统的解空间，同时也确定了位于解空间之外的伴生系统。
2．映射限界上下文
在全局分析阶段，EAS系统的问题空间被分解为业务场景下的各个业务服务。遵循业务维度的V型映射过程，需要针对这些业务服务进行归类和归纳，获得各个业务主体，再根据亲密度和限界上下文的特征对业务主体的边界进行调整，并运用验证原则验证业务边界的合理性。之后，根据管理维度的工作边界、技术维度的应用边界逐步对限界上下文做进一步的调整。
（1）归类与归纳
V型映射过程从识别业务服务的语义相关性与功能相关性开始。
语义相关性主要针对业务服务名的名词。例如，在客户活动业务流程中，诸如“创建合同”“添加附加合同”“指定合同承担者”等业务服务都包含“合同”一词，可归类到同一个业务主体，如图20-28所示。
功能相关性则从业务服务的业务目标进行归类，如图20-29中的业务服务都与市场管理的业务目标有关，可归类到同一个业务主体。
通过语义相关性和功能相关性对业务服务进行归类后，可以进一步针对它们表达的概念建立抽象，寻找共同特征完成对类别的归纳。例如，图20-29中的业务服务涵盖了市场需求、需求订单、客户需求等领域概念，它们都可以提炼为一个更高的抽象层次——市场。这也是图中业务主体名称的由来。从中也可发现，虽然归类与归纳属于V型映射过程的两个环节，但这两个环节并没有清晰的界限，在进行归类时，可以同时进行归纳。
无论是寻找领域概念的共同特征，还是识别领域行为的业务目标，都需要一种抽象能力。在进行抽象时，可能出现“向左走还是向右走”的困惑，因为抽象层次的不同，抽象的方向或依据亦有所不同。这时就需要做出设计上的决策。
例如对识别出来的“员工”与“储备人才”领域概念，可以抽象出“人才”的共同特征，得到图20-30所示的人才业务主体。从共同的业务目标考虑，储备人才又是服务于招聘和面试的，似乎归入招聘业务主体才是合理的选择，如图20-31所示。
还有第三种选择，就是将储备人才单独抽离出来，形成自己的储备人才业务主体，如图20-32所示。
该如何抉择呢？我认为须得思考识别业务主体的目的。业务主体是架构映射过程的中间产物，并非最终的设计目标。业务主体是对业务服务的分类，为限界上下文的识别提供了参考。因此，选择人才主体，还是招聘主体，或者单独的储备人才主体，都需要从限界上下文与领域建模的角度去思考。如果暂时分辨不清楚，可以先做出一个初步选择，待所有的业务主体都归纳出来之后，在梳理业务主体的边界时再决定。
识别业务主体不是求平衡，更不是为了让设计的模型更加好看。业务主体是根据业务相关性进行归类和归纳的，必然会出现各个业务主体包含的业务服务数量不均等的情形。例如，与项目管理有关的业务主体，包含的业务服务数量非常不均匀。项目业务主体的业务服务数量最多，如图20-33所示。
