domain-driven-design - 没有 CQRS 的 EventStore

Question

我看过很多关于 EventStores 的文章，但所有文章都伴随着关于 CQRS 的讨论。

我们希望使用 EventStores 来集成有界上下文，但希望坚持使用传统的 ORM 来读取/写入聚合，以避免命令/查询和单独的读取模型在我们的例子中会增加太多的复杂性。

鉴于将这两个概念一起讨论如此流行，人们会认为它们注定要一起生活 - 与为聚合/CQRS/读取模型实现 EventStore 相比，在没有 CQRS 的情况下做 EventStore 'lite' 是否存在陷阱？

Answer 1

跑到NoSql Distilled - 你可以通过几天无所事事来节省大量时间，而是阅读它并绘制出你所追求的东西。如果你正在“读/写聚合”，你应该考虑像 RavenDB 这样的主要数据库。

请注意，事件存储标签是针对 JOliver 事件存储的，它具有关键的架构概念

你也有一些事情会稍微倒退，因为要产生事件，你的域以特定的方式构建以促进这一点。与您在问题中提出事物的方式形成鲜明对比的关键事物（解释得很糟糕和/或不公平：我想使用事件存储来存储事件 - 我可以自己做剩下的事情）

1. 事件按聚合进行批处理 - 它是事件管理的真正单元

2. 派往某事。

如果您不想要事件源域模型，请研究队列管理解决方案。这是一件非常合法的事情——只是不要假装 Event Store 是一个通用的事件发布子队列。

让 Dispatcher Project to Denormalizers 构建读取模型很容易——您可以使用各种奇特的东西，但使用 SQL SB 等熟悉的工具和 PetaPoco 等简单的数据库层就可以了。

你真的用过 CommonDomain 和 EventStore 吗？您是否阅读过 nuget 中的自述文档？你看过2 JOliver 的视频吗？

• CQRS - 2010 年犹他州代码训练营 - 第 1 部分和第2部分
• CQRS - 初学者介绍
• Jonathan Oliver 谈 Event Sourcing 和 EventStore @ E-VAN 2011 年 10 月 25 日

Answer 2

我们想使用 EventStores 来集成有界上下文

可以将事件存储用作消息队列，另外还有一个好处是它是持久的，并且新订阅者可以请求所有过去的事件。

但要坚持使用传统的 ORM 来读取/写入聚合，以避免命令/查询和单独的读取模型在我们的例子中会增加太多的复杂性。

顺便说一句，您仍然可以通过简单地使用单独的读取模型而不是行为模型来获得 CQRS 的一些好处。

总的来说，您可以在不使用事件源的情况下使用 EventStore ，但是您应该确保它支持您的集成场景的所有要求。除了事件存储之外，您可能还需要其他组件。更一般地，事件存储可用于存储任何时间序列数据。