3.1
HealthMonitor业务体系

业务体系梳理是案例分析和设计的第一步。在本节中，我们将以通用语言的形式给出对HealthMonitor案例的需求和功能的描述。同时，基于这些需求和功能，我们也会阐述对应的案例建模流程，从而为本章后续内容的展开提供基础。

3.1.1 案例描述和通用语言

我们先来梳理HealthMonitor案例系统的业务背景。在健康管理理念日益普及的当下，为了让用户更好地管理自身的健康状况，我们希望开发一套健康监测系统，帮助用户对自身的各项健康指标进行有效监控，并构建完整的健康信息库。

这些原始需求构成了案例的最高层次通用语言，后续从业务到技术的各个层次的通用语言都将由此展开。从案例的业务背景上看，设计HealthMonitor系统要求开发人员对健康管理领域有一定了解。同时，案例描述也比较抽象，我们能够获取一些有用的概念，但还远远不足以进行领域建模。这时候就需要开发人员和业务人员进行深入的沟通，从而形成双方都能理解的、更为细化的通用语言。基于这一目的，我们继续对案例系统进行讨论，并梳理对应的核心功能要求。

接下来，我们来简单模拟开发人员和业务人员之间的几个主要讨论场景。

开发人员：用户健康检测的具体过程是怎么样的？

业务人员：用户健康检测的依据是各种健康数据，而健康数据的收集需要用户完成对应的健康任务。也就是说，每当用户执行一个健康任务，系统就应该为他生成一条数据。

开发人员：那健康任务又是怎么设计的呢？

业务人员：用户可以执行很多个健康任务，针对一组需要执行的健康任务，我们需要为用户指定一个健康计划。一个用户只能指定一个健康计划，而一个健康计划可以被多个用户使用。

开发人员：用户执行了健康任务之后应该能获取对应的健康信息，这些健康信息应该如何管理呢？

业务人员：用户可以一次执行多个健康任务，也可以多次执行同一个健康任务，而所有健康任务所生成的健康信息会统一挂靠到该用户的健康档案中。系统需要确保一个用户只有一个健康档案，并确保健康档案数据的实时性和完整性。至于对用户健康档案中的数据进行挖掘，可以在其他专用系统中实现，暂时不属于本系统的功能范围。

……

这样的讨论可以进行很多轮。从这些讨论中，我们可以进一步梳理HealthMonitor案例系统的主要功能要求，如下：

❑能够建设统一的健康检测功能，用户可以通过这一功能管理自己的健康信息；

❑能够建立一个健康任务管理平台，维护着系统中所有可用的健康任务信息；

❑能够确保一个健康任务的完成会对某一项健康指标产生影响；

❑能够建立一个健康计划管理平台，根据现有的健康任务生成健康计划；

❑能够根据模板预生成一批常规的健康计划；

❑能够让用户选择一个合适的健康计划，从而执行计划中包含的健康任务；

❑能够允许用户根据现有的健康任务创建一个专属于自己的健康计划；

❑能够确保用户有一份完整的健康档案；

❑能够把用户执行健康任务所产生的健康信息实时更新到他的健康档案。

上述需求的描述仍然比较抽象，但至少已经宏观地给出了健康监测系统的核心概念和功能。根据这些描述，我们已经可以初步确定该案例系统的边界，明确哪些功能必须实现，而哪些功能则不需要实现。

3.1.2 案例建模流程

显然，上文给出的信息不够全面，在有限的信息中，我们需要通过DDD中的战略设计和战术设计方法对这些信息进行分析和抽象，并形成可以落地的实现方案。在本节中，我们将讨论如何基于已知的案例系统的描述来完成案例建模的流程，如图3-1所示。

在图3-1中，我们首先需要对案例系统进行分析，并识别子域。这部分工作属于战略设计的内容，也是开展后续一切工作的前提。在这一环节中，我们将产生案例系统的子域名称、描述以及对应的类别。

明确了子域之后，就可以分析限界上下文。在这一环节，我们需要考虑系统最终的物理表现形式，因为单体或者微服务等架构体系与限界上下文之间的划分和集成有很大关系。

子域和限界上下文一旦确定，战略设计就完成了，我们进入战术设计的环节。首先要完成对领域模型对象的梳理，包括聚合、实体和值对象。在这一环节中，我们不会罗列所有领域模型对象，但会给出各个限界上下文对应的聚合定义以及部分核心的实体和值对象。

接下来考虑的是领域事件。可以认为领域事件反映的是聚合对象的一种状态变更过程。因此，明确了领域模型对象之后，领域事件也就不难梳理了。我们在这一环节也会给出部分核心的领域事件。同时，我们也会基于事务机制考虑领域事件与数据一致性之间的关联关系。

然后，我们进一步梳理应用服务。这部分内容相对明确，我们将从命令服务和查询服务这两大类服务入手，给出各个限界上下文涉及的应用服务的名称及功能。

最后，整个流程会回到限界上下文，我们会讨论案例系统涉及的上下文映射和集成。在这一环节，我们需要基于限界上下文之间的映射关系，分析采用何种手段来实现集成过程。

请注意，在整个建模流程中我们并没有对资源库等基础设施类组件专门展开讨论，原因在于这部分组件通常偏向于技术实现，而与案例建模的关系并不是很大，我们在后文会更多讨论它们的实现方式。 i/FHcaMZxrItSCeTLttuyzgRlZFrZcqDrIpF3HmDRt8x+SYi0/Wr8g7quUL9ygYw