领域事件与最终一致性

领域事件代表了领域中发生的某些事情, 当 Eric Evan 原创的 DDD 书本发行的时候并没有把它定义为一种领域驱动设计 (DDD) 模式，但现在在DDD 中已经是一种战术元素，而且是一个完整的领域模型成员。 最终一致性 是一种改进规模和性能的设计方法，而且领域事件能作为触发器承载领域信息进而协助实现， Florin Preda 在最近的博客文章 中作出了解析。

对于多数开发者都很熟悉的事务型一致性工作流中，客户在系统中执行一个命令，这个系统为维护事务中的领域一致性的需要而运行所有操作。当操作全部成功或全部失败的时候客户会收到反馈，没有中间地带。

对于常见于分布式系统的最终一致性工作流中，客户同样在系统中执行一个命令，但这个系统只为维护事务中的领域一致性运行部分的操作。剩余的操作在系统前后一致后运行。

Preda 指出虽然事务型一致性看起来更加直观和容易使用，但他觉得某些场景中最终一致性有一点优势。在他描述的四种场景中，用 A 操作之后进行 B 操作来作为例子：

1. 操作 B 执行时间长。
2. 操作 B 本来就是异步的，例如依赖了一个异步机制。
3. 操作 B 是通过在相同的 有界上下文 中使用不同于操作 A 的聚合。
4. 操作 B 在不同于操作 A 的有界上下文中执行。

Preda 将场景 3 和 4 关联到领域驱动设计（DDD），他相信在这两种场景中选择最终一致性将引导到比使用传统事务工作更好的设计。领域事件在这里可以很有用。领域事件是在领域专家相关的领域中发生的某些事情的代表，它们通过作为触发器启动工作流的下一个步骤和承载领域信息需求来促进最终一致性。

写同一主题的 Mike Mogosanu 声称在现实世界的用例中 事务型一致性工作流很罕见；一个业务流程经常包含一系列的用例和使用 Unit of Work (UoW) 模式去持久化一组更改，从技术观点来看，它幼稚的解决方案会将事情复杂化，尤其是在分布式应用中。

Mogosanu 相信一个包含不同有界上下文的业务流程应该考虑变为最终一致性，其在每个有界上下文中有最少一个领域用例。领域用例负责让聚合保持始终如一，在这里 UoW 模式会很有用，而且公布触发其它用例启动的领域事件，最终可以把整个系统带到一致的状态。

为了举例说明他的想法，在实现用 Azure Service Bus 消息系统来做事件传送的 C# 应用 中，Preda 使用了 Vaughn Vernon 在书本 实现领域驱动设计 中提到的设计的一个简化版本。

查看英文原文： Domain Events and Eventual Consistency

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。