也许这个问题很傻，但我有点困惑。假设我们想要利用这种模式：
-
企业应用程序中的事件存储范围究竟是什么？
-
一个事件存储是在多个进程之间共享，还是只是一个过程中的概念？
-
应用程序关闭时事件会发生什么？它们是绑定到应用程序"实例"还是绑定到一个应用程序？
-
事件存储和具有发布服务器/订阅服务器的MessageBus之间有什么区别(部分原因是我们可以存储消息历史记录？
-
谁对信息的幂等性负责？
- 这句话的实际意思是什么："有趣的是，即使在所涉及的各种资源(如消息队列和持久存储)中没有分布式事务，EventStore也能够确保完全的事务体验。这是通过将分布式事务分解成更小的部分并单独执行每个事务来实现的">(来自这个项目)我不明白如何将事务分解为几个小部分，即使所有事务本身都是事务性的，也可以取代分布式事务
企业应用程序中的事件存储范围究竟是什么？
在这个意义上，事件存储就像一个数据库。它不受任何给定应用程序的限制。然而，它可以由业务/语言边界限定范围。例如，如果将系统划分为多个子系统，则每个子系统都可以有自己的事件存储实例。
一个事件存储在多个进程之间共享，或者只是一个过程概念？
这不是一个进程内概念。它在进程/应用程序之间共享，就像数据库一样
当应用程序关闭时，事件会发生什么？他们一定要应用程序"实例"还是应用程序？
事件存储将存储应用程序要求其存储的所有事件。事件由流ID键控，流ID通常是聚合根的ID。这不绑定到特定的应用程序实例。
事件存储和MessageBus之间有什么区别使用发布服务器/订阅服务器(部分原因是我们可以存储消息历史
消息历史记录的存储基本上是功能方面的核心区别。用例中的区别在于，消息总线用于在端点之间传递消息，其中作为事件存储用于持久化消息(通常是事件)。
谁对消息幂等性负责？
您作为开发人员。事件存储将事件视为由流键控的序列化数据，可能具有版本控制功能。使用版本控制，它可以处理某些冲突，但由您来确定消息是否是幂等的。
我不明白如何将一笔交易分割成几个小部分，即使所有这些本身都是事务性的，也可以取代分布式交易
看看澄清传奇模式。其基本思想是，不是将多个操作分组在一个分布式事务下，而是将操作分解为多个部分。如果某个部分失败(这将导致分布式tx中的回滚)，则会发送一条错误消息，允许相关方回滚操作。这可以被视为一种补偿形式，也是分析许多业务场景的一种更自然的方式。例如，当支付交易被视为无效时，它不会被删除，而是添加了补偿交易。这种表现活动的方式更符合现实，因为在现实中很少有"未完成"的事情。
有多少问题！
企业应用程序中的事件存储范围究竟是什么？
事件存储不是一种合适的模式，它是一种通常用于两种不同(但密切相关)模式的技术：事件源和命令与查询责任分离。作为一个"存储"，它只是一种保持与业务相关的应用程序状态的方法。
这两种模式通常与领域模型结合使用，因为它们与Evans在领域驱动设计中引入的模式配合得很好。
EventStore允许您持久化域事件(Event Sourcing方式)或应用程序事件(也称为命令，在CQRS中)。它不同于文档和关系存储，因为您不保存模型的状态，而是保存导致它的事件。但是，您可以使用RDBMS或文档数据库来存储事件。
然后，要检索实体，只需按顺序向前播放每个注册的事件/命令即可。快照可用于加快此过程。
事件存储是在多个进程之间共享，还是只是一个进程内概念？
它取决于存储实现，但没有任何理由阻止它在多个进程和/或应用程序之间使用。
当应用程序关闭时，事件会发生什么？它们是绑定到应用程序"实例"还是绑定到一个应用程序？
同样，这取决于存储实现。最简单的事件存储将事件保存到编号文件中，因此当应用程序关闭时，事件仍然存在(这总是让我想起汤普森的话："我们有持久的对象，我们称它们为文件")
但是，如果您的应用程序真的需要，没有什么可以阻止您在内存中拥有一个易失性事件存储。我会将它实现为一个只附加的集合，以保持条目顺序。
事件存储和具有发布服务器/订阅服务器的MessageBus之间有什么区别(部分原因是我们可以存储消息历史记录？
消息总线是传递消息的工具。事件(和命令)是消息，因此您可以使用它来传递它们。相反，事件存储是一种持久性工具。
谁对消息幂等性负责？
在大多数常见的场景中，设计域模型的人。在非DDD系统中，是设计消息(事件或命令)的人。事实上，幂等性必须由消息的接收者来保证，而不是由技术本身来保证。
考虑到这一点，EventStore可以在检测到重复消息时合并它们。但这本身并不意味着模型是幂等的。
这句话的实际意思是什么："有趣的是，即使在所涉及的各种资源(如消息队列和持久存储)中没有分布式事务，EventStore也能够确保完全的事务体验。这是通过将分布式事务分解为更小的部分并单独执行每个部分来实现的"(来自该项目)我不明白将事务分解为几个小部分，即使所有事务本身都是事务性的，也可以取代分布式事务。
这取决于作者赋予"完全交易体验"的含义。对我来说，这句话看起来是错误的，因为它会打破布鲁尔定理。
你可以从微软和Greg Young那里找到有用的CQRS之旅。
明天见，在办公室：-)