Question

我知道CQRS可以在有或没有event sourcing的情况下实现，但是它在另一方面有用吗？没有event sourcing的{{1}}是否有意义？如果是这样，应该如何实施？

Answer 1

是的。

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

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

与不使用事件源就可以使用CQRS的方式相同，也可以不使用CQRS来使用事件源。两者彼此独立，只是偶然地很好地契合了彼此。

Answer 2

没有CQRS的事件来源是否有意义？

是的，从某种意义上说，CQRS和事件源是相互关注的。

这就是上面所说的-您有一个管理历史的模型，既可以对历史进行更新以响应命令，又可以根据该历史构造对查询的响应。

class BankAccount {
    final History<Transactions> transactions;

    void deposit(Money money) {...}
    Money computeInterestAccruedSince(Date lastReview) { ... }

}

Answer 3

CQRS is about separating the reads from the writes. Write operations need things like locking, guaranteed order, and always the latest state. In classical systems (relational databases) you would also give this guarantees to read operations, which comes with a huge performance impact and big issues when it comes to scalability. That's why in CQRS you give read operations a separate copy of the data which is optimized for fast reads, e.g. it is denormalized and put into more efficient, faster systems (e.g. a memory cache), I'd call this a "read view [on the system's data]".

CQRS works without ES, because you can create the optimized read view from a traditional data store (e.g. a relational database).

ES does work without CQRS, but only if the number of events is reasonably small. Because you are storing all the changes of the system in a database and every read has to use the same database and iterate over all events that it needs to fulfill the query. Eventually there will be too many events that need to be read in order to answer and the time it takes to answer will become too long.

Answer 4

我还没有看到使用不带CQRS的ES的情况，因为只有在不需要跨多个实体的任何查询/分析功能时，才会出现这种情况。这是所有情况的99％；）

如果要查询多个实体，肯定会需要CQRS之类的东西，因为除了使用事件源外，您将采用其他方式查询数据。（除非您想在每次查询时重播所有事件。）但是如何实现CQRS部分并不是一成不变的。它只是描述了阅读和写作是两个以不同方式处理的独立问题。

所以通常：不，这没有任何意义。

没有CQRS的事件采购

4 个答案: