没有CQRS的事件采购

k13*_*13i 7 language-agnostic architecture cqrs event-sourcing

我知道CQRS可以在有或没有的情况下实现event sourcing,但它在另一端起作用吗?难道event sourcingCQRS有意义吗?如果是这样,应如何实施?

Gol*_*den 6

是的,它确实。

基本上,事件源的整个想法只是存储导致当前状态的更改,而不是存储当前状态。这样,通过事件源,您可以自动获得历史记录,并可以对数据进行时间序列分析,并尝试从过去学习。

是否使用CQRS是一个完全不同的故事:CQRS是关于将应用程序的编写与读取分开的。

与可以不使用事件源使用CQRS的方式相同,也可以不使用CQRS使用事件源。两者是彼此独立的,它们只是偶然地非常适合彼此。

  • 通过给出一个没有 CQRS 的事件溯源示例,这个答案将会得到极大的改善。正如 @coderbyheart 在他的回答中所说,如果您不保留单独的读取端,则必须直接从事件存储中读取,而这很快就会变得不切实际。因此,实际上,事件溯源似乎确实需要 CQRS。 (2认同)

小智 6

CQRS 是关于将读取与写入分离。写操作需要诸如锁定、保证顺序和始终最新状态之类的东西。在经典系统(关系数据库)中,您还会为读取操作提供这种保证,这会带来巨大的性能影响和可扩展性方面的大问题。这就是为什么在 CQRS 中你给读取操作一个单独的数据副本,该副本针对快速读取进行了优化,例如它被非规范化并放入更高效、更快的系统(例如内存缓存)中,我称之为“读取视图 [在系统的数据]”。

CQRS 在没有 ES 的情况下工作,因为您可以从传统数据存储(例如关系数据库)创建优化的读取视图。

ES 确实可以在没有 CQRS 的情况下工作,前提是事件数量相当小。因为您将系统的所有更改存储在数据库中,并且每次读取都必须使用相同的数据库并迭代完成查询所需的所有事件。最终会有太多的事件需要阅读才能回答,回答所需的时间会变得太长。