下载掌阅APP，畅读海量书库
立即打开
通过聚合的状态变化，我们可以捕获对应的领域事件。领域事件本身表达的是聚合状态变化的一种结果。而领域事件的处理过程可以发生在触发事件的限界上下文内部，但更多时候我们需要跨多个限界上下文来完成对某个聚合状态变化的传播。本节将讨论HealthMonitor案例系统所涉及的各种领域事件。同时，我们还将讨论另一个由领域事件衍生出来的话题，即事务。
在HealthMonitor案例系统中，原则上每一个限界上下文都可以触发并传播一批领域事件，而领域事件的触发时机是在各个聚合对象的状态发生变化时。图3-14展示了各个限界上下文可能发布的部分领域事件及其对应的触发时机。
图3-14 限界上下文和领域事件示例
可以看到，在Monitor限界上下文中，当用户申请健康监控成功之后，该上下文可以发送一个“监控已启动”（MonitorInitialized）事件；而当系统为用户创建了健康计划之后，也可以生成一个“计划已制定”（PlanGenerated）事件。同样，对Plan限界上下文而言，当系统根据一组健康任务生成一个有效的健康计划时，我们可以生成一个“计划已创建”（PlanCreated）事件。
在通常情况下，我们都会设计并实现一个类似日志收集和分析的系统，专门订阅这些领域事件，然后将其交由大数据平台处理。但从业务需求而言，我们并不需要订阅所有领域事件，而是可以有选择地进行处理。在HealthMonitor案例系统中，对这些领域事件，Record限界上下文是潜在的订阅者，因为该上下文需要记录与用户健康档案相关的所有信息。
请注意，并不是所有的领域事件都属于健康档案的范畴。对用户健康档案而言，我们只需要记录与用户健康行为以及结果相关的数据即可。图3-15展示了Record限界上下文对用户健康档案相关领域事件的订阅效果。
在图3-15中，我们注意到只有来自Monitor限界上下文的MonitorInitialized和PlanGenerated事件被Record限界上下文订阅，这些事件背后的业务数据属于健康档案信息。而Plan限界上下文中的PlanCreated事件本身代表系统中生成通用健康计划的过程，这个健康计划并不包含任何与用户相关的属性，也就不在用户健康档案的记录范畴中。
图3-15 用户健康档案相关领域事件的订阅效果示意图
请注意，Record限界上下文在接收并处理完来自其他限界上下文的领域事件时，也可以发布一个表示健康档案信息已经被成功记录的领域事件，如“健康任务已存档”（TaskRecorded）事件。图3-16在图3-15的基础上对这一过程做了补充。
图3-16 HealthMonitor案例系统中的领域事件
请注意，上一小节所讨论的领域事件会在各个限界上下文之间传播。如果我们采用的是微服务架构，那么各个限界上下文实际上就是不同的微服务，数据在各个微服务之间进行传播时就需要考虑事务。
针对事务，我们也来看一个具体场景。在HealthMonitor案例系统中，通过对前面内容的分析，Monitor限界上下文中用户健康信息相关的领域事件最终都要为Record限界上下文所消费，而这个过程要确保数据一致性，如图3-17所示。
图3-17 领域事件和数据一致性示意图
在图3-17中，一旦用户在Monitor限界上下文中成功申请了健康监控就会触发Monitor-Initialized事件。Record限界上下文在消费这条事件之后，就会把该事件所对应的用户健康信息记录下来。正如上一小节所讨论的，这时候Record限界上下文会发送一个TaskRecorded领域事件。而只有这个TaskRecorded领域事件被成功发布并消费，我们才能认为整个与健康任务相关的处理过程在数据上达到了一致性。图3-17描述了这种场景下的事务需求，这时候Monitor限界上下文充当了TaskRecorded领域事件的消费者。