下载掌阅APP，畅读海量书库
立即打开
识别子域和分析限界上下文是开展案例设计的第一步。在本节中，我们将基于通用语言梳理HealthMonitor中的子域和上下文。
面对有限的业务需求信息，我们想要确定一个系统中的子域，基本思路是找到以下问题的答案。
❑核心域的通用语言是什么？
战略设计的第一步是找到系统的核心域，并根据核心域的定位和作用梳理其通用语言。核心域的通用语言包括该子域的名称以及基本需求约束。
❑核心域的支撑子域和通用子域是什么？
有了核心域，下一步就是判断系统是否只要一个核心域就能满足建模需求。如果不是，那就判断是否需要相应的支撑子域和通用子域。支撑子域和通用子域不一定都需要，但有时候系统也会存在多个支撑子域或通用子域。
❑核心域如何与其他子域协作和集成？
系统的交互和集成以核心域为主体展开，当核心域面对支撑子域或通用子域时，使用的协作和集成策略往往是不一样的，这方面需要根据具体的子域来分析和设计。
回到案例，我们把需要构建的目标系统称为健康监控系统。回顾上一节给出的该系统的初始通用语言，并对其中的关键名词进行筛选，得到这样的结果：健康监控、健康信息、健康任务、健康指标、健康计划、健康档案。
根据这些关键名词，我们可以初步梳理案例系统中的业务领域了。
首先，我们注意到的关键名词是“健康监控”。毫无疑问，健康监控是整个案例系统的入口。用户可以申请加入健康监控平台，从而为自身创建一个健康监控器。由此我们可以得到案例的第一个业务领域，把它命名为Monitor。
Monitor业务领域包含的内容如下：
❑接收用户的申请并创建健康监控器；
❑根据健康监控内容制定合适的健康计划；
❑获取用户的健康信息；
❑取消对用户的健康监控。
然后，我们注意到一组关键名词是“健康计划”、“健康任务”和“健康指标”。从描述上看，健康计划和健康任务之间应该是一对多的关系。从系统建模角度来看，我们可以把这3个关键名词都划分到一个业务领域。但从复杂度上看，健康任务又包含了健康指标，比较适合被划分为一个独立的业务领域。这样，健康计划也可以被看作一个独立业务领域。我们把这两个业务领域分别命名为Task和Plan。
其中Task业务领域包含的内容有：
❑创建和管理健康任务；
❑设置健康任务对应的健康指标。
而Plan业务领域则包括如下内容：
❑创建和管理健康计划；
❑管理健康计划中的健康任务；
❑创建和管理健康计划模板。
最后，我们还注意到“健康档案”和“健康信息”这两个关键名词。通过对业务领域的分析，我们发现这两个关键名词实际上指的是同一个事物，即用户自身所拥有的一份健康信息。因此，我们把这两个关键名词进行整合，统一归到健康档案这个业务领域，并把它命名为Record。
Record业务领域中应该实现的内容包括：
❑初始化一份健康档案；
❑基于健康任务的执行结果更新健康档案。
我们对上述4个业务领域的关系进行了梳理，如图3-2所示。
图3-2 HealthMonitor案例系统中的业务领域及其关联关系
在DDD中，图3-2中的每一个业务领域都可以被划分为独立的子域。因此，HealthMonitor案例系统的子域划分也就很明确了，如图3-3所示。
图3-3 HealthMonitor案例系统中的四大子域
在图3-3中，我们可以明确Monitor子域的作用是让用户执行健康监控；Plan子域和Task子域分别用于制定健康计划和处理健康任务；而Record子域则用来完善健康档案。可以看到，通过子域的划分，原始的通用语言得到扩展，功能归属和界限也得到了明确。
从子域的类型而言，我们认为Monitor子域是一个核心子域，Plan子域和Task子域则是为了完成健康监控而设计的支撑子域。至于Record子域，因为在通用语言中提到用户的健康档案可以被用到数据统计分析等其他场景，所以倾向于把它归为通用子域，如图3-4所示。
图3-4 HealthMonitor案例系统中的子域类型
在本书中，基于战略设计的基本思路，我们将每个子域都映射到一个限界上下文。因此，我们可以快速得到HealthMonitor案例系统的限界上下文。简单起见，我们使用与子域同样的名称来为各个限界上下文命名。
明确了限界上下文的数量和名称之后，我们下一步需要梳理上下文之间的映射关系。从图3-4中，我们不难明白这4个限界上下文之间的映射关系。基于上一章中关于上下文映射的讨论，我们进一步梳理HealthMonitor案例系统中的限界上下文映射关系图，如图3-5所示。
图3-5 HealthMonitor案例系统中限界上下文映射关系
系统中限界上下文核心交互的时序图如图3-6所示。
图3-6 HealthMonitor案例系统中限界上下文核心交互的时序图
最后，关于限界上下文需要讨论如何从物理上划分上下文之间的边界，这个问题属于DDD实现技术的范畴，我们会在下一章中分析DDD实现模型时具体展开阐述。通常，我们会把限界上下文设计成一个个独立的服务，然后通过一定的集成策略完成上下文之间的交互。因此，在物理上，HealthMonitor案例系统至少存在4个独立的服务。根据限界上下文的名称，我们把它们分别命名为monitor-service、plan-service、task-service和record-service，如图3-7所示。
图3-7 HealthMonitor案例系统中限界上下文与微服务系统架构
请注意，在本书中，服务的命名采用×××-service的形式，避免与服务中具体某个Service层组件重名（例如在plan-service服务中，很可能存在如PlanService这样的Service组件）。至于如何完成各个服务之间的集成过程，我们在3.6节中还会进一步讨论。