DDD案例(2):从领域分析到代码实现(3)

4)运用验证原则

运用正交原则单一抽象层次原则,可以进一步确定限界上下文业务边界的合理性。

例如,为何选择将问题而非项目成员归入项目上下文?除了因为项目成员与组织之间存在黏性,在概念上,问题其实属于项目的子概念,在层次上处于“劣势”地位。遵循单一抽象层次原则,项目与问题并不在同一个抽象层次。相反,以招聘业务主体和储备人才业务主体为例,二者就没有非常明显的“上下级”层次关系。它们之间的关系或许比较亲密,却处于平等的层次。


在运用单一抽象层次原则时,业务主体的命名会影响我们对主体关系的判断。如果命名过于抽象,就可能使得过高的抽象隐隐然包含别的主体。以市场业务主体和合同业务主体为例,市场的抽象层次明显高于合同(即合同的概念也应属于市场的范畴),故而带来两个设计选择:要么将合同业务主体纳入市场业务主体,进而形成一个市场上下文,要么将市场业务主体命名为订单,而订单与合同显然处于同一层次。


正交原则警醒了设计者:限界上下文之间不能存在重叠内容。为何需要单独分离出文件共享上下文与通知上下文?因为诸如员工、储备人才、合同等业务主体都需要调用文件上传下载功能,项目、合同、招聘等业务主体都需要调用消息通知功能。如果不分离出来,一旦文件上传下载或者消息通知的实现有变,就会影响到相关的业务主体,造成“霰弹式修改”[6]的代码坏味道,违背了正交原则。


运用单一抽象层次原则与正交原则,对前面获得的业务主体进一步梳理和验证,可初步获得如图20-39所示限界上下文的草案。


DDD案例(2):从领域分析到代码实现(3)


在图20-39中,订单上下文与项目上下文就是在对业务主体的边界进行梳理,并通过验证原则验证后调整的结果。


5)工作边界的识别

从工作边界识别限界上下文是一个长期过程,其中,也牵涉到需求变更和新需求加入时的柔性设计[8]168

如前所述,限界上下文之间是否允许进行并行开发可以作为判断工作边界分配是否合理的依据。在EAS限界上下文草案中,我发现报表上下文与客户、合同、订单、项目、员工等上下文都存在非常强的依赖关系。如果这些上下文没有完成相关的特性功能,就很难实现报表上下文。由于报表上下文的诸多统计报表与各自的业务强相关,如查看项目统计报表用例只需统计项目的信息,因此可以考虑将这些用例放到与业务强相关的限界上下文中。


结合工作边界和业务边界,我认为工作日志业务主体的边界过小,且从业务含义看,可将其视为员工管理的一项子功能,因而决定将工作日志合并到员工上下文,同样地,也将考勤业务主体合并到员工上下文。这实际也遵循了验证原则中的奥卡姆剃刀原则

储备人才和招聘之间的关系类似于工作日志和员工之间的关系,我最初也想将储备人才合并到招聘上下文中。然而,客户对需求的反馈打消了这一决策考量。因为该软件集团旗下还有一家软件学院,集团负责人希望将软件学院培养的软件开发专业学生也纳入企业的储备人才库中。这一需求影响了储备人才的管理模式,也扩充了储备人才的领域内涵,使它与招聘领域形成了正交关系,为它的“独立”增加了有力的砝码。

一些限界上下文之间的依赖无法通过需求分析直观呈现出来,这就有赖于上下文映射对这种协作(依赖)关系的识别。一旦明确了这种协作关系,定义了服务契约,就可以利用MockStub解除开发的依赖,实现并行开发。


通过工作边界识别限界上下文的一个重要出发点是激发团队成员对工作职责的主观判断。这种边界也就是第9章提及的针对团队的“渗透性边界”。团队成员需要对自己负责开发的需求抱有成见,尤其是在面对需求变更或新增需求的时候。


EAS系统的设计开发过程中,客户提出了增加员工培训的需求。该需求要求人力资源部能够针对员工的职业规划制订培训计划,确定培训课程,实现对员工培训过程的全过程管理。考虑到这些功能与员工上下文有关,我最初考虑将这些需求直接分配给员工上下文的领域特性团队。然而,团队的开发人员提出:这些功能虽然看似与员工有关,但实际上是一个完全独立的培训领域,包括了培训计划制订、培训提名、培训过程管理等业务知识,与员工管理的业务是正交的。最终,我们选择为培训建立一个专门的领域特性团队,同时引入培训上下文。


类似文件共享和通知这样一些属于支撑子领域或者通用子领域的限界上下文,可能具有并不均匀的粒度,且互相之间又不存在关联。此时,可维持限界上下文的业务边界不变,然后视粒度酌情将它们分配给一个或多个领域特性团队。如果该支撑功能需要团队成员具备一定的专业知识,也可将它单独抽离出来,建立专门的组件团队。如果它提供的功能具有普遍适用性,不仅可以支撑目标系统,还可以支持组织内其他软件系统,就可以考虑将其演进为企业范围内的框架或平台。这些框架和平台就不再属于目标系统的范围了(在系统上下文边界之外)。


根据需求变化以及对团队开发工作的分配,我们调整了限界上下文,如图20-40所示。


在图20-40中,将工作日志与考勤合并到了员工上下文,同时为了应对新需求的变更,增加了培训上下文,并暂时去掉了报表上下文。之所以说“暂时”,是因为还需要对其做一些技术层面的判断。


DDD案例(2):从领域分析到代码实现(3)

上一篇:航空公司系统是怎样炼成的


下一篇:DDD案例(2):从领域分析到代码实现(4)