6

我正在查看有关在使用 Event Sourcing/DDD/CQRS 方法设计的应用程序中进行查询的帖子。

据我了解，事件是对域对象状态的更改。对状态的更改将作为历史记录/事件在数据库中进行维护（任何 sql/no sql）。

如果用户想要查询特定聚合根的当前状态，它将涉及获取事件历史记录。

当用户将查询特别是业务特定查询时，他/她将对当前状态而不是事件历史感兴趣。

CQRS 中的查询或“Q”部分如何与事件溯源一起使用？

考虑我有一个域对象“帐户”作为聚合根。账户 AR 将经历很多变化，即贷记借记。事件存储将有贷记和借记事件。

考虑用户需要获取帐户的当前余额，事件历史流将如何适应这里？用户将如何获取给定帐户的当前余额？

我无法理解，对于特定业务的事件查询历史记录将如何有用？

-Prakhyat MM

4

3 回答 3

6

我建议您阅读 Greg Young 的更多文章（他就像 CQRS 和 Event Sourcing 之父），例如：CQRS, Task Based UIs, Event Sourcing... agh。

对不起我的英语不好，我来自巴拉圭。但我真的很喜欢 DDD - CQRS - ES，我想说明一点。

“投影”（也称为物化视图）的使用和“最终一致性”的概念是每个 CQRS 实践者都应该非常了解的基本原理。事件存储用于查询。位于 CQRS 的 Command 端，而不是 Query 端。您可以使用总线将存储在事件存储中的事件发送到查询端，以便处理和生成读取模型或视图模型，您可以从中查询。无论如何，事件存储本身就是一个查询模型。

看起来您是 Java 人，但是，您仍然可能想查看Microsoft 的 CQRS Journey。希望这对您有所帮助，并激励您对 DDD / CQRS / ES（业务线应用程序的新三重奏）进行更多研究。

于 2014-12-29T13:21:35.143 回答
5

您将使用事件流投影到读取模型中，其中包含查询端 (Q) 所需的那些信息。例如，您可以有一个“账户余额”预测，它跟踪所有更改账户余额的事件，但可能忽略账户流中的其他事件（例如所有者更改）。然后，投影以可以非常快速地查询的方式保存该信息，例如，在内存中或以 为键的小型读取模型数据库表(accountId, balance)中accountId（例如，数据库可以是键值存储）。

我建议进一步阅读 CQRS 概念，例如this one或this one。

于 2014-08-28T09:40:27.440 回答
5

有趣的是，最近越来越多的人发现使用事件存储作为读取模型，将预测和“正确”读取模型留到绝对必要时。

我们都知道处理预测会增加复杂性。至少您必须创建新模型，为读取模型建立 DAL 并创建投影以将事件转换为读取模型更改，并将这些投影绑定到来自您的商店的事件流。它需要更多的代码，更多的活动部件，其中一些不容易测试。读取端的架构更改也需要迁移。

看来，对于许多场景而言，读取所有事件（正确分区）可能足以拥有您的“读取模型”。系统真正变大不需要太多时间，因此您需要读取数万个事件来创建一个 UI 屏幕。但在达到这一点之前，您可以只阅读事件。可以使用文件系统来存储事件，尽管像 EventStore 这样的工具是免费的并且非常易于使用。可能会添加一些索引。

这种方法可以让您显着稳定领域，您可以获得有关系统如何工作的更多知识，调整事件并真正准备好将“正确的”读取模型带入系统，但您可能不必这样做。

Adam Dymitruk 写了一篇关于它的博客文章，即使您不想采用这种方法，您也可能会发现它值得一读。早在 2012 年，Greg Young 还在EventStore 作为阅读模型进行了一次演讲。

于 2017-01-22T14:12:26.053 回答