我正在尝试学习EventStore，我喜欢这个概念但是当我尝试在实践中应用时，我会陷入同样的困境。 我们来看看代码：
foreach (var k in stream.CommittedEvents)
{
//handling events
}
有两个问题：
当应用程序在某些维护后启动时，我们如何在一个维护中添加书签 什么事件开始阅读的安全方式？是否有使用模式？
一旦事件全部消耗完，循环结束......消息到达运行时间怎么样？我希望呼叫阻塞，直到一些新消息到达（当然需要在一个线程中处理）或者有类似BeginRead EndRead的东西。
我是否必须绑定ESB来处理运行时事件，或者EventSore是否提供了一些工具来执行此操作？
我尝试用示例来更好地解释 假设汇总是一个金融投资组合，该应用程序是一个向交易者显示该投资组合的应用程序。假设交易者连接到Web应用程序，他会查看自己的投资组合。当前状态将是整个历史记录，因此我必须阅读大量记录以重现状态。我想这可以通过一个所谓的快照完成，但是谁负责创建它？什么时候应该选择创建聚合？怎么能猜出聚合的快照存在？ 对于运行时部分：一旦用户查看重建的投资组合状态，实时部分就开始运行。用户可以通过在市场中成功执行该订单来下订单并创建新的头寸。基础设施如何更新投资组合？我希望，但也许我完全错了，让相同的事件流成为新事件的来源新的长期位置，否则我有两个处理状态的路径相同的聚合。我想知道这是策略应该如何工作，即使我觉得有两个州代理有点棘手，可能会重叠。 只是为了澄清我如何担心重叠：
我在流式传输事件之前订阅事件总线以更新投资组合的状态。总线上出现了一些“开仓事件”：我必须处理它们，但是由于尚未实现，投资组合可能处于正确状态。即使我能够处理这样的事件，我会在阅读流时再次找到它们。
更加阴险：我打开了流，我读了所有事件并创建了一个状态。然后我订阅了总线：总线上的一些消息发生在steram读取结束和订阅开始之间的中间：这些事件丢失且聚合不正确。
请耐心等待，我的英语很差，争论很棘手，希望我设法分享我的疑问：）
答案 0 :(得分：10)
目前的状态将是整个历史，所以我必须阅读 可能有很多记录来重现状态。我猜这个 可以通过所谓的快照来完成，但谁负责 创造它？
在CQRS和事件源中，查询由projections提供，这些查询是由聚合发出的事件生成的。您不使用从事件存储重构的聚合实例来显示信息。
术语快照特指事件存储的优化，它允许重建聚合而无需重放所有事件。
预测本质上是事件处理程序，它维护聚合的非规范化视图。从聚合中发出的事件可能在带外发布，并且投影订阅并处理这些事件。例如，如果存在显示摘要信息的要求，则投影可以组合多个聚合。在交易应用程序的情况下，每个视图通常包含来自各种聚合的数据。预测是以消费者驱动的方式设计的 - 应用程序需求决定了所需的基础数据的不同视图。
使用此类工作流程，您必须在整个应用程序中拥抱最终的一致性。例如，如果最终用户正在查看其投资组合并启动新交易，则UI必须订阅更新以反映更新的投影以异步方式。
请查看here以了解CQRS和事件采购的概述。