我正在尝试学习 EventStore，我喜欢这个概念，但是当我尝试在实践中应用时，我陷入了同一点。让我们看看代码：
foreach (var k in stream.CommittedEvents)
{
//handling events
}
关于这个的两个问题：
当一个应用程序在一些维护后启动时，我们如何以一种安全的方式为开始读取的事件添加书签？有模式可以使用吗？
一旦事件全部消耗完，循环就结束了……消息到达运行时间呢？我希望呼叫阻塞，直到一些新消息到达（当然需要在线程中处理）或有类似 BeginRead EndRead 的东西。
我是否必须绑定 ESB 来处理运行时事件，或者 EventSore 是否提供了一些工具来执行此操作？
我试着用一个例子更好地解释 假设聚合是一个金融投资组合，并且应用程序是一个向交易者显示该投资组合的应用程序。假设交易者连接到网络应用程序并查看他自己的投资组合。当前状态将是整个历史记录，因此我必须阅读大量记录才能重现该状态。我想这可以通过所谓的快照来完成，但谁负责创建它？什么时候应该选择创建聚合？怎么能猜出聚合的快照存在？对于运行时部分：用户一看到重建的投资组合状态，实时部分就开始运行。用户可以下订单，并且可以通过在市场上成功执行该订单来创建新头寸。基础设施如何更新投资组合？我会期待，但也许我完全错了，拥有相同的事件流是该新事件new long position的来源，否则我有两条路径处理同一聚合的状态。我想知道这是否是该策略应该如何运作的，即使我觉得拥有两个国家代理有点棘手，这可能会重叠。只是为了澄清我如何担心重叠：
- 我知道事件必须是幂等的，所以我知道无论如何它一定不是问题，
- 但是让我们考虑以下几点：
在流式传输事件以更新投资组合的状态之前，我订阅了事件总线。公共汽车上出现了一些“未平仓事件”：我必须处理它们，但由于尚未实现，投资组合可能未处于处理它的正确状态。即使我能够处理此类事件，我也会在阅读流时再次找到它们。
更阴险：我打开流并读取所有事件并创建一个状态。然后我订阅总线：总线上的一些消息发生在 steram 读取结束和订阅开始之间的中间：这些事件丢失并且聚合未处于正确状态。
请大家耐心等待，我的英语很差而且争论很棘手，希望我设法分享我的疑问:)