rest - CQRS、事件溯源和 Web 应用程序

Question

当我阅读一些 CQRS 资源时，有一个反复出现的点我没有注意到。例如，假设客户端发出一个命令。该命令由域集成，因此可以刷新其域模型(DM)。另一方面，该命令保存在 Event-Store 中。这是最常见的场景。

1) 当我们说 DM 被刷新时，我假设数据被持久化在底层数据库中(如果有的话)。我对吗 ？否则，我们将处理内存 transient 模型，我认为这不是一件好事？ (状态不应该保留在客户端请求之外的服务器端的内存中)。

2)如果数据是持久的，我想依赖它的读取模型会自动更新，因为每个请求它的客户端都会在应用程序中生成一个新的“状态/上下文”(在 Web 应用程序或 RESTful 架构的情况下) ) ?

3)如果命令被持久化，这是否意味着我们处理事件源(当我们使用 CQRS 时通过构造)？事件溯源是否会使数据库更新过程无效？ (好像状态是从 Event-Store 重建的，维护数据库似乎没用)？

CQRS 是否仅适用于多数据库系统(当数据在单独的数据库上传播时)，如果它处理内存 transient 模型，它是否适合 Web 应用程序或 RESTful 服务？

Answer 1

1) 如前所述，唯一真正存储的东西是事件。
命令所做的唯一事情是在引发事件之前进行一致性检查。在伪代码中:

public void BorrowBook(BorrowableBook dto){
    if (dto is valid)
        RaiseEvent(new BookBorrowedEvent(dto))
    else
        throw exception
}

public void Apply(BookBorrowedEvent evt) {
    this.aProperty = evt.aProperty;
    ...
}

当前状态通过顺序应用检索。因此，您必须在设计阶段非常注意，因为有一些常见的陷阱要避免(也许您已经阅读过它，但让我建议 this Martin Fowler 的文章)。

到目前为止一切顺利，但这只是事件溯源。如果您决定使用不同的数据库来持久化聚合的状态，CQRS 就会发挥作用。
在我的项目中，我们有一个预测，即每 x 分钟将新事件(来自事件存储)应用于聚合并将结果保存在 MongoDB 的单独实例上(表示层将访问此数据库以进行读取)。这个型号分明是 最终一致 ，但通过这种方式，您可以真正将命令(写入)与查询(读取)分开。

2) 如果您决定将写入模型与读取模型分开，您可以使用多种选项使它们同步:

每x秒从最后一个检查点应用事件(一些解决方案提供快照以避免重新应用大量命令)

订阅事件并在引发事件后立即更新读取模型的投影

3) 唯一存储的是事件。事实上，我们有一个事件存储，而不是一个命令存储 :)

数据库没用？要看!您需要重新申请多少个事件才能使聚合达到当前状态？
三？也许你不需要有一个用于读取模型的数据库