问题业务主体的业务服务数量也比较多，如图20-34所示。

项目成员业务主体的业务服务最少，如图20-35所示。

不用担心业务主体的这种不均等。遵循V型映射过程，针对业务服务进行业务相关性分析获得的业务主体只是候选的限界上下文，还需要我们根据业务服务的亲密度进一步梳理业务主体的边界。

通过对业务相关性的归类和归纳，初步获得图20-36所示的业务主体视图。

（2）亲密度分析

一旦确定了各个业务主体的业务服务，就可以通过分析亲密度的强弱来调整业务服务与业务主体之间的关系。例如，“从储备人才转为正式员工”业务服务究竟属于储备人才主体，还是属于员工主体？虽说该业务服务需要同时用到储备人才和员工的领域知识，但由于其服务价值是生成员工记录，储备人才的信息仅仅作为该领域行为的输入，因此它与员工业务主体的亲密度显然更高。

亲密度分析也可以判断业务服务的归类是否合理。例如，项目主体中的创建迭代、开始迭代等业务服务牵涉到迭代这一领域概念，它与项目概念固然存在较亲密的关系，但问题概念与迭代概念之间的亲密关系也不遑多让，进一步，项目成员与问题之间的亲密关系也有目共睹。划分业务主体时，项目计划、迭代等概念被放到了项目主体，问题却没有被一并放入，显得领域知识的分配有些失衡。用亲密度来解释，就是迭代与问题之间的亲密度几乎等于项目与项目计划、迭代之间的亲密度，而问题与项目之间的亲密度却要明显低于问题与迭代之间的亲密度。为了保证领域知识分配的均衡，可以考虑两种设计方案：

q将项目主体、问题主体和项目成员主体合并，形成项目上下文；

q将项目计划、迭代等造成亲密度不均匀的领域概念单独剥离出来，定义独立的项目计划业务主体。

（3）判断限界上下文的特征

从知识语境看，合同上下文与员工上下文都具有合同（contract）领域概念，二者在各自的业务主体边界内，代表了各自的领域概念。前者为商务合同，后者为劳务合同。

员工主体与储备人才主体存在几乎完全相同的领域模型，如图20-37所示。

两个模型除了员工Employee与储备人次Candidate的名称不同，几乎是一致的。我们是否可以把这两个概念抽象为Talent，由此来来统一领域模型？如图20-38所示。

面向对象设计思想鼓励这样的抽象，以避免代码的重复。然而，若从领域模型的知识语境看，这是两个完全不同的领域模型：员工属于员工管理的领域范畴，储备人才并非正式员工，是招聘的目标。以模型中的项目经验Project Experience为例，虽然员工和储备人才的项目经验具有完全相同的属性，但它们面向的关注点是迥然不同的，如市场人员就完全不关心储备人才的项目经验。

从业务能力看，员工与储备人才之间存在清晰的界限，提供了各自独立的业务能力，一个服务于员工的日常管理，一个服务于人才的招聘。虽说“从储备人才转为正式员工”需要二者的结合，但在储备人才转为正式员工之后，二者就不存在任何关系了。

因此，员工和储备人才这两个领域模型应该放在不同的限界上下文。这也体现了领域驱动设计与面向对象设计之间的差异。

ps：在具体的业务语境中，员工涉及的相关业务远大于储备人才，在张老师举例的业务需求中未展开。比如员工对于办公的诉求，拥有电脑、内网访问权限、分配座位、付出劳动获得薪酬和福利等。员工属于HR域，但和办公域强相关，而储备人才显然只服务于招聘活动。