我正在努力学习EventStore，我喜欢这个概念，但当我试图在实践中应用时，我会陷入同样的困境。让我们看看代码：
foreach (var k in stream.CommittedEvents)
{
//handling events
}
关于这一点的两个问题：
当一个应用程序在经过一些维护后启动时，我们如何在安全的方式什么事件开始阅读？有什么模式可以使用吗？
一旦所有事件都被消耗掉，循环就结束了。。。消息到达运行时间如何？我希望在一些新消息到达之前(当然需要在线程中处理)或者有类似BeginRead EndRead的东西，调用会被阻塞。
我是否必须绑定ESB来处理运行时事件，或者EventSore是否提供了一些功能来实现这一点？
我试着用一个例子来更好地解释假设聚合是一个金融投资组合，而应用程序是一个向交易员显示该投资组合的应用程序。假设交易者连接到网络应用程序，查看自己的投资组合。当前的状态将是整个历史，所以我必须阅读潜在的大量记录来重现状态。我想这可以通过一个所谓的快照来完成，但谁负责创建它？应该选择何时创建聚合？如何猜测聚合的快照存在？对于运行时部分：用户一看到重建的投资组合状态，实时部分就开始运行。用户可以下订单，通过在市场上成功执行该订单可以创建新的头寸。基础架构如何更新投资组合？我希望，但也许我完全错了，让相同的事件流成为新事件新多头的来源，否则我有两条路径处理相同聚合的状态。我想知道这是否是该战略的运作方式，即使我觉得有两个国家特工有点棘手，但这可能会重叠。只是为了澄清我对重叠的恐惧：
- 我知道事件必须是幂等的，所以我知道它一定不是无论如何，问题是
- 但让我们考虑以下几点：
在流式传输事件以更新投资组合的状态之前，我订阅了一个事件总线。公交车上出现了一些"空仓事件"：我必须处理它们，但可能投资组合还没有处于正确的状态来处理它，因为它还没有实现。即使我能够处理这样的事件，当我阅读流时，我也会再次找到它们。
更阴险的是：我打开流，阅读所有事件，然后创建一个状态。然后我订阅了总线：总线上的一些消息发生在steram读取结束和订阅开始之间的中间：这些事件丢失，聚合状态不正确。
请大家耐心等待，我的英语很差，争论也很棘手，希望我能和大家分享我的疑虑：)
当前状态将是整个历史，所以我必须阅读可能会有大量的记录来重现状态。我想是这样可以通过所谓的快照来完成，但谁负责创建它？
在CQRS和事件源中，查询由聚合发出的事件生成的投影提供服务。您不使用从事件存储中重构的聚合实例来显示信息。
术语快照专门指的是对事件存储的优化，它允许在不重播所有事件的情况下重建聚合。
投影本质上是维护聚合的非规范化视图的事件处理程序。聚合发出的事件被发布，可能在带外，投影订阅并处理这些事件。例如，如果存在显示摘要信息的需求，则投影可以组合多个聚合。在交易应用程序的情况下，每个视图通常都包含来自各种聚合的数据。预测是以消费者驱动的方式设计的——应用程序需求决定了所需底层数据的不同视图。
使用这种类型的工作流，您必须在整个应用程序中实现最终的一致性。例如，如果最终用户正在查看他们的投资组合并启动新的交易，则UI必须订阅更新，以异步方式反映更新后的预测。
请查看此处，了解CQRS和活动来源的概述。