也许这个问题很愚蠢，但我有点困惑。 假设我们想要利用这种模式：
企业应用程序中的事件存储范围究竟是什么？
事件存储是在多个进程之间共享，还是只是一个进程内概念？
应用程序关闭时事件会发生什么？它们是绑定到应用程序“实例”还是应用程序？
事件存储和带有 Publisher/Subscriber 的 MessageBus 有什么区别（我们可以存储消息历史的部分事实？
谁负责消息的幂等性？
【问题讨论】：
标签： design-patterns cqrs neventstore
企业应用程序中的事件存储范围究竟是什么？
在这个意义上，事件存储就像一个数据库。它不受任何给定应用程序的限制。但是，它可以通过业务/语言边界来确定范围。例如，如果您将系统划分为子系统，则每个子系统都可以拥有自己的事件存储实例。
一个事件存储是否在多个进程之间共享，或者只是一个 进程中的概念？
这不是一个进程中的概念。它像数据库一样在进程/应用程序之间共享。
应用程序关闭时事件会发生什么？他们是否一定会 应用程序“实例”还是应用程序？
事件存储将存储应用程序要求存储的所有事件。事件由流 ID 键入，该 ID 通常是 aggregate root 的 ID。这不受特定应用程序实例的约束。
事件存储和 MessageBus 有什么区别 使用发布者/订阅者（我们可以存储消息的部分事实 历史？
消息历史的存储基本上是功能方面的主要区别。用例的不同之处在于消息总线用于在端点之间传递消息，而事件存储则用于持久化消息（通常是事件）。
谁负责消息的幂等性？
您作为开发者。事件存储将事件视为由流键入的序列化数据，可能带有版本控制。通过版本控制，它可以处理某些冲突，但由您决定消息是否具有幂等性。
我无法理解如何将交易分成几个小部分， 即使所有都是事务本身也可以取代分布式 交易。
看看Clarifying the Saga pattern。基本思想是，不是将多个操作分组到单个分布式事务下，而是将操作分解为多个部分。如果某个部分失败（这将导致分布式 tx 中的回滚），则会发送一条错误消息，允许相关方回滚操作。这可以看作是一种补偿形式，是分析许多业务场景的一种更自然的方式。例如，当付款交易被视为无效时，它不会被删除，而是会添加补偿交易。这种表示活动的方式更符合现实，因为在现实中很少有“未完成”的事情。
【讨论】：
有多少问题！
企业应用程序中的事件存储范围究竟是什么？
事件存储不完全是一种模式，它是一种通常与两种不同（但密切相关）模式一起使用的技术：Event Sourcing 和Command and Query Responsibility Segregation。作为“存储”，它只是一种持久化与业务相关的应用程序状态的方式。
这两种模式通常与domain model 结合使用，因为它们与 Evans 在Domain Driven Design 中介绍的模式配合得很好。
EventStore 允许您持久化域事件（事件溯源方式）或应用程序事件（又名命令，在 CQRS 中）。它不同于文档和关系存储，因为您不保存模型的状态，而是保存导致它的事件。 但是，您可以使用 RDBMS 或文档数据库来存储事件。
然后要检索实体，您可以简单地按顺序播放注册的每个事件/命令。快照可用于加快此过程。
事件存储是在多个进程之间共享，还是只是一个进程内概念？
这取决于商店的实现，但没有理由阻止它在多个进程和/或应用程序中使用。
应用程序关闭时事件会发生什么？它们是绑定到应用程序“实例”还是应用程序？
同样，这取决于商店的实施。最简单的事件存储将事件保存到编号的文件中，因此当应用程序关闭时，事件仍然存在
（这总是让我想起 Thompson 的话：“我们有持久对象，我们称它们为文件”）。
但是，如果您的应用程序确实需要它，没有什么能阻止您在内存中拥有一个易失性事件存储。我会将其实现为一个仅追加的集合，以保持条目顺序。
事件存储和带有 Publisher/Subscriber 的 MessageBus 有什么区别（我们可以存储消息历史记录的一部分？
消息总线是传递消息的工具。事件（和命令）是消息，因此您可以使用它来传递它们。相反，事件存储是一种持久性工具。
谁负责消息的幂等性？
在最常见的情况下，设计领域模型的人。在非 DDD 系统中，是设计消息（事件或命令）的人。事实上，幂等性必须由消息的接收者来保证，而不是由技术本身来保证。
鉴于此，EventStore 可以在检测到重复消息时合并它们。但这并不能使模型本身具有幂等性。
这句话的真正含义是什么：“有趣的是，即使不存在跨所涉及的各种资源的分布式事务，例如消息队列和持久性存储，EventStore 也能够确保完全事务性的体验。这是实现的通过将分布式事务分解成更小的部分并单独执行每个部分”（来自这个项目）我无法理解如何将事务分成几个小部分，即使所有事务本身都是事务性的也可以取代分布式事务。
这取决于作者赋予“完全交易体验”的含义。 对我来说，这句话看起来不对，因为它会破坏Brewer's theorem。
您可以从 Microsoft 和 Greg Young 那里找到有用的 CQRS Journey。
明天在办公室见 :-)
【讨论】：