【发布时间】：2019-05-10 01:12:23
【问题描述】：
我知道CQRS 可以在有或没有event sourcing 的情况下实现，但它在另一边有效吗？没有CQRS 的event sourcing 有意义吗？如果有，应该如何实现？
【问题讨论】：
标签： architecture language-agnostic cqrs event-sourcing
【发布时间】：2019-05-10 01:12:23
【问题描述】：
是的，确实如此。
基本上，事件溯源的整个想法只是存储导致当前状态的更改，而不是存储当前状态。这样，通过事件溯源，您可以自动获得历史记录，并可以对您的数据进行时间序列分析，并尝试从过去中学习。
您是否使用 CQRS 是一个完全不同的故事：CQRS 是将写入应用程序与读取应用程序分开。
与您可以在不使用事件溯源的情况下使用 CQRS 的方式相同，您可以在不使用 CQRS 的情况下使用事件溯源。两者都是相互独立的，只是不经意间非常契合。
【讨论】：
-
通过给出一个没有 CQRS 的事件溯源的例子，这个答案会得到很大的改善。正如@coderbyheart 在他的回答中所说，如果您不保留单独的读取端，则必须直接从事件存储中读取，这很快就会变得不切实际。因此，实际上，事件溯源似乎确实需要 CQRS。
CQRS 是关于将读取与写入分开。写操作需要诸如锁定、保证顺序和始终保持最新状态之类的东西。在经典系统（关系数据库）中，您还可以为读取操作提供这种保证，这会带来巨大的性能影响和可伸缩性方面的大问题。这就是为什么在 CQRS 中，您为读取操作提供了一个单独的数据副本，该副本针对快速读取进行了优化，例如它被非规范化并放入更高效、更快的系统（例如内存缓存）中，我称之为“[系统数据的读取视图]”。
CQRS 无需 ES 即可工作，因为您可以从传统数据存储（例如关系数据库）创建优化的读取视图。
ES 确实可以在没有 CQRS 的情况下工作，但前提是事件数量相当少。因为您将系统的所有更改存储在数据库中，并且每次读取都必须使用相同的数据库并遍历它需要完成查询的所有事件。最终将有太多的事件需要阅读才能回答，并且回答所需的时间会变得太长。
【讨论】：
没有 CQRS 的事件溯源有意义吗？
是的，从某种意义上说，CQRS 和事件溯源是正交关注点。
正如它在锡上所说的那样 - 您有一个管理历史记录的模型，既可以对历史记录应用更新以响应命令，又可以根据该历史记录构建对查询的响应。
class BankAccount {
final History<Transactions> transactions;
void deposit(Money money) {...}
Money computeInterestAccruedSince(Date lastReview) { ... }
}
【讨论】：
我还没有看到您在不使用 CQRS 的情况下使用 ES 的情况，因为只有当您不需要跨超过 1 个实体的任何查询/分析功能时才会出现这种情况。 99% 的情况下这是一项要求；）
如果您想查询多个实体，您肯定需要像 CQRS 这样的东西，因为您将应用不同的方式来查询您的数据，而不是使用事件溯源。 （除非您想在每次查询时重播所有事件。）但是，如何实现 CQRS 部分并不是一成不变的。它只是描述了阅读和写作是两个以不同方式处理的独立问题。
所以总的来说：不，这没有任何意义。
【讨论】：