design-patterns - EventStore 和应用程序生命周期

Question

也许这个问题很愚蠢，但我有点困惑。
假设我们想要利用这种模式:

企业应用程序中的事件存储范围究竟是什么？

事件存储是在多个进程之间共享，还是只是一个进程内概念？

当应用程序关闭时，事件会发生什么？它们是绑定(bind)到应用程序“实例”还是应用程序？

事件存储和带有 Publisher/Subscriber 的 MessageBus 有什么区别(我们可以存储消息历史的部分事实？

谁负责消息的幂等性？

这句话实际上是什么意思:“有趣的是，即使不存在跨所涉及的各种资源的分布式事务，例如消息队列和持久存储，EventStore 也能够确保完全事务性的体验。这是通过拆分来实现的将分布式事务分成更小的部分并单独执行每个事务”(from this project)我无法理解如何将事务分成几个小部分，即使所有事务本身都是事务性的，也可以替换分布式事务。

Answer 1

what exactly is the event storage scope in an enterprise application?

在这个意义上，事件存储就像一个数据库。它不受任何给定应用程序的限制。但是，它可以通过业务/语言边界来确定范围。例如，如果您将系统划分为子系统，则每个子系统都可以拥有自己的事件存储实例。

Does an event storage share among multiple processes, or is just an in-process concept?

它不是一个过程中的概念。它在进程/应用程序之间共享，就像数据库一样。

What happens to events when the application close? Are they bound to an application "instance" or to an application?

事件存储将存储应用程序要求它存储的所有事件。事件以流 ID 为键，通常是 aggregate root 的 ID。 .这不受特定应用程序实例的约束。

What are the differences between an event storage and a MessageBus with Publisher/Subscriber ( a part the fact we can store the message history?

消息历史的存储基本上是功能方面的主要区别。用例的不同之处在于消息总线用于在端点之间传递消息，而事件存储则用于持久化消息(通常是事件)。

Who's responsible for the message idempotence?

你作为开发者。事件存储将事件视为由流键入的序列化数据，可能带有版本控制。通过版本控制，它可以处理某些冲突，但由您决定消息是否具有幂等性。

I can't understand how breaking a transaction in several small pieces, even if all are transactional per-se can replace a distributed transaction.

看看 Clarifying the Saga pattern .基本思想是，不是将多个操作分组到单个分布式事务下，而是将操作分解为多个部分。如果某个部分失败(这将导致分布式 tx 中的回滚)，则会发送一条错误消息，允许相关方回滚操作。这可以看作是一种补偿形式，是分析许多业务场景的一种更自然的方式。例如，当付款交易被视为无效时，它不会被删除，而是会添加补偿交易。这种表示事件的方式更符合现实，因为在现实中很少有“未完成”的事情。