cqrs - 事件存储 : learning how to use

Question

我正在尝试学习 EventStore，我喜欢这个概念，但是当我尝试在实践中应用时，我陷入了同一点。
让我们看看代码:

foreach (var k in stream.CommittedEvents)
{ 
   //handling events
}

关于这个的两个问题:

当一个应用程序在一些维护后启动时，我们如何在一个
安全方式 什么事件开始读取？有模式可以使用吗？

一旦事件全部消耗完，循环就结束了……消息到达运行时间呢？我希望调用阻塞，直到一些新消息到达(当然需要在线程中处理)或有类似 BeginRead EndRead 的东西。

我是否必须绑定(bind) ESB 来处理运行时事件，或者 EventSore 是否提供了一些工具来执行此操作？

我试着用一个例子更好地解释
假设聚合是一个金融投资组合，并且应用程序是一个向交易者显示该投资组合的应用程序。假设交易者连接到网络应用程序并查看他自己的投资组合。当前状态将是整个历史记录，因此我必须阅读大量记录才能重现该状态。我想这可以通过所谓的快照来完成，但谁负责创建它？什么时候应该选择创建聚合？怎么能猜出聚合的快照存在？
对于运行时部分:用户一看到重建的投资组合状态，实时部分就开始运行。用户可以下订单，并且可以通过在市场上成功执行该订单来创建新头寸。基础设施如何更新投资组合？我会期待，但也许我完全错了，将相同的事件流作为新事件的源 新多仓 ，否则我有两条路径处理同一聚合的状态。我想知道这是否是该策略应该如何运作的，即使我觉得拥有两个国家代理有点棘手，这可能会重叠。
只是为了澄清我如何担心重叠:

我知道事件必须是幂等的，所以我知道它一定不是
无论如何，

但让我们考虑以下内容:

我订阅了一个事件总线 之前 流式传输事件以更新投资组合的状态。公共(public)汽车上出现了一些“未平仓事件”:我必须处理它们，但由于尚未实现，投资组合可能未处于处理它的正确状态。即使我能够处理此类事件，我也会在阅读流时再次找到它们。

更阴险:我打开流并读取所有事件并创建一个状态。然后我订阅总线:总线上的一些消息发生在 steram 读取结束和订阅开始之间的中间:这些事件丢失并且聚合未处于正确状态。

请大家耐心等待，我的英语很差而且争论很棘手，希望我设法分享我的疑问:)

Answer 1

The current state will be the whole history, so I have to read potentially a lot of records to reproduce the status. I guess this could be done by a so called snapshot, but who's responsible for creating it?

在 CQRS 和事件溯源中，查询由 projections 提供服务。它们由聚合发出的事件生成。您不使用从事件存储重构的聚合实例来显示信息。

术语快照专门指事件存储的优化，它允许在不重播所有事件的情况下重建聚合。

投影本质上是事件处理程序，它维护聚合的非规范化 View 。从聚合发出的事件被发布，可能是带外的，并且投影订阅并处理这些事件。例如，如果存在显示摘要信息的需求，则投影可以组合多个聚合。对于交易应用程序，每个 View 通常包含来自各种聚合的数据。投影是以消费者驱动的方式设计的——应用程序需求决定了所需的底层数据的不同 View 。

使用这种类型的工作流程，您必须在整个应用程序中实现最终的一致性。例如，如果最终用户正在查看他们的投资组合并开始新交易，则 UI 必须订阅更新以以异步方式反射(reflect)更新的预测。

看看here有关 CQRS 和事件溯源的概述。