EventStore:学习如何使用

Question

我正在尝试学习EventStore,我喜欢这个概念,但是当我尝试在实践中应用时,我会陷入同样的​​困境.我们来看看代码:

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

两个问题:

• 当应用程序在某些维护后启动时,我们如何以安全的方式书签哪些事件开始读取？有使用的模式吗？

• 一旦事件全部被消耗,循环结束......消息到达运行时间怎么样？我希望呼叫阻塞,直到一些新消息到达(当然需要在一个线程中处理)或者有类似BeginRead EndRead的东西.

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

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

• 我知道事件必须是幂等的,所以我知道它一定不是问题,
• 但是让我们考虑以下几点:

我在流媒体事件之前订阅了一个事件总线,以更新投资组合的状态.总线上出现了一些"开仓事件":我必须处理它们,但是由于尚未实现,投资组合可能处于正确状态.即使我能够处理这样的事件,我会在阅读流时再次找到它们.

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

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

Answer 1

当前状态将是整个历史记录,因此我必须阅读大量记录以重现状态.我想这可以通过一个所谓的快照完成,但是谁负责创建它？

在CQRS和事件源中,查询由聚合发出的事件生成的投影提供.您不使用从事件存储重构的聚合实例来显示信息.

术语快照特指事件存储的优化,它允许重建聚合而不重放所有事件.

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

使用此类工作流程,您必须在整个应用程序中拥抱最终的一致性.例如,如果最终用户正在查看他们的投资组合并启动新交易,则UI必须订阅更新以反映更新的投影以异步方式.

请在此处查看CQRS和事件采购的概述.