多少问题!
企业应用程序中的事件存储范围究竟是什么?
事件存储不是一种正确的模式,它是一种通常与两种不同(但密切相关)模式一起使用的技术:事件溯源和命令和查询责任分离。作为“存储”,它只是保持与业务相关的应用程序状态的一种方式。
这两种模式经常与领域模型结合使用,因为它们与 Evans 在领域驱动设计中引入的模式配合得很好。
EventStore 允许您持久化域事件(事件溯源方式)或应用程序事件(又名命令,在 CQRS 中)。它不同于文档和关系存储,因为您不保存模型的状态,而是保存导致它的事件。但是,您可以使用 RDBMS 或文档数据库来存储事件。
然后要检索实体,您可以简单地按顺序播放注册的每个事件/命令。快照可用于加快此过程。
事件存储是在多个进程之间共享,还是只是一个进程内概念?
这取决于商店的实现,但没有理由阻止它在多个进程和/或应用程序中使用。
当应用程序关闭时,事件会发生什么?它们是绑定到应用程序“实例”还是应用程序?
同样,它取决于商店的实施。最简单的事件存储将事件保存到编号的文件中,因此当应用程序关闭时,事件仍然存在(这总是让我想起 Thompson 的话:“我们有持久性对象,我们称它们为文件”)。
但是,如果您的应用程序确实需要它,没有什么能阻止您在内存中拥有一个易失性事件存储。我会将其实现为仅附加的集合,以保持输入顺序。
事件存储和带有 Publisher/Subscriber 的 MessageBus 之间有什么区别(我们可以存储消息历史的事实的一部分?
消息总线是传递消息的工具。事件(和命令)是消息,因此您可以使用它来传递它们。相反,事件存储是一种持久性工具。
谁负责消息的幂等性?
在最常见的情况下,设计领域模型的人。在非 DDD 系统中,是设计消息(事件或命令)的人。事实上,幂等性必须由消息的接收者来保证,而不是由技术本身来保证。
鉴于此,EventStore 可以在检测到重复消息时合并它们。但这并不能使模型本身具有幂等性。
这句话实际上是什么意思:“有趣的是,即使不存在跨所涉及的各种资源(例如消息队列和持久存储)的分布式事务,EventStore 也能够确保完全事务性的体验。这是通过拆分来实现的将分布式事务分成更小的部分并单独执行每个事务”(来自这个项目)我无法理解如何将事务分成几个小部分,即使所有事务本身都是事务性的,也可以替换分布式事务。
这取决于作者赋予“完全交易体验”的含义。对我来说,这句话看起来是错误的,因为它会破坏布鲁尔定理。
你会发现这个来自 Microsoft 和 Greg Young 的CQRS Journey很有用。
明天在办公室见 :-)