2

我一直在为一个使用 J Oliver 的 EventStore 和 mongo 作为持久层的新项目研究事件溯源,但遇到了一些问题:

  1. 在尝试事件源之前,我的域一直保存到一个数据库中,并且我一直在使用 Udi 的域事件模式,这对我来说非常有效,NHibernate 管理工作单元。但是,我最终得到了一个可以影响多个聚合的工作单元,例如。

    我“结帐”我的购物篮聚合引发了一个事件,处理程序通过创建一个发票聚合来响应该事件,该发票聚合反过来引发一个事件(这只是一个示例)

    在这种情况下,我有一个改变两个聚合根的工作单元 - 在事件存储中,我可以将引发的事件添加到两个不同的事件流中,但它们不会以原子方式持久化(第一个可能成功,第二个失败) . 那么人们怎么做才能避免这种情况发生呢?

  2. 在github主页上,它建议您可以使用流畅的界面来配置EventStore,但是当我下载源代码时,编译它并在示例中查看wireup类似乎不可用 - 它是否在不同的分支中? (我有师傅)

  3. 处理 IStoreEvents impl 的推荐方法是什么?作为类似于 Nhibernates 会话工厂的单例?

4

1 回答 1

5
  1. 在您给出的示例中,您实际上已经发生了多个工作单元。当聚合被修改时,它会调度一个事件。其他的东西会监听那个事件并处理另一个工作单元等等。

    EventStore 的设计方式仍然可以适应您的场景,但它将是三个独立的工作单元。您只需将 Udi 的 DomainEvents“拯救”解决方案插入您自己的 IPublishEvents 实现中,然后在 AsynchronousCommitDispatcher 中运行它。在真正的 DDD 中,单个聚合是一个工作单元——根据定义,这是一致性边界。

  2. 大约 8 小时前,我做了一个推送,将流利的东西作为编译的一部分。尝试从 master 拉下最新的。

  3. IStoreEvents 设计为多线程的,因此您可以在应用程序中安全地将其配置为单例。当您从 IStoreEvents 打开会话时,该会话是单线程的,不应在应用程序内的线程之间共享。

于 2011-03-22T11:18:35.963 回答