CQRS/ES - 我理解正确吗？

Question

我想总结一下我对 CQRS/ES 的了解。前段时间我开始阅读这个主题，由于我是年轻的开发人员，我并不了解这个概念的各个方面。我将尝试通过一些示例流程来描述我对 CQRS 的理解。因此，定义该架构的一般步骤，我们有以下流程：

1. 用户向我们的控制器发出请求。在该控制器方法中，我们创建指定的 Command（例如 CreateOrder）并将其传递给 Handler。

2. 全局消息总线（或处理程序）负责将命令路由到指定的命令处理程序。所以这里我们将命令传递给 CreateOrderHandler

3. 在处理程序中，我们创建 Aggregate root（在本例中为 OrderAggregate）并应用来自 EventStore 的所有事件。在 EventStore 中，我们只保留与指定聚合相关的事件数据（由全局 id 定义）。所以在这一步之后，我们就有了当前状态的聚合。

4. 创建聚合后，我们将命令传递给它，并在方法中验证命令是否可以执行。如果我们可以运行此命令，我们将创建 Event（在本例中为 OrderCreated）。

5. 如果没有任何异常，我们将 Event 保存到 EventStore 中（我认为使用 NoSql DB 和简单的保存事件很简单）

6. 现在处理程序将保存的事件传递给我们的 Denormalizer 类，该类是创建 View Models 的网关。因此，如果 denormalizer 得到一些事件，它会更新/创建我们应用程序中的所有 ViewModel。我们将 ViewModel 保存在单独的数据库中。

7. 用户可以查询更新的视图模型。

所以我这是我对 CQRS/ES 理解的简化版。请在每一层上纠正我。我的问题是：

在第 4 步中，我们创建了聚合，我们应该将此聚合保存在数据库中吗？保持当前状态。我在这里错过了什么吗？我们创建聚合只是为了检查创建事件的可能性？

我应该有实体吗？如果我在第 5 步中是正确的，我可以更新聚合实体并在我的视图模型中使用它们。我在这里有最大的困惑。

感谢所有回答；）

Answer 1

在第 4 步中，我们创建了聚合，我们应该将此聚合保存在数据库中吗？ 保持当前状态。我在这里错过了什么吗？我们创造了 聚合仅用于检查创建事件的可能性？

如果您使用 EventStore，ES 本身会保留您的聚合状态。您在命令处理程序中谈论“创建”聚合，但通常最好说在命令处理程序中聚合是从 ES 重新水合的。

聚合使用命令（或其数据）并引发（域）事件，这些事件在 ES 中应用以跟踪聚合的状态更改，并且相同的事件由事件处理程序（如非规范化程序）处理。

在通常描述的流程中，我在第 3 步之前有一个命令验证步骤。 无论如何，前段时间我试图描绘components of a typical CQRS/ES flow；网上有很多，但也许有用

Answer 2

聚合状态源自应用到它的过去事件。所以你不需要存储它的状态，因为它是从事件流派生的。话虽如此，您可能希望创建快照以避免非常长的事件历史记录。在设计快照系统之前，有必要测试重新应用先前事件列表的速度有多快。

当您向聚合发出命令时，它会分两个阶段处理它。第一阶段主要检查它是否可以运行。如果是这样，它会构建一个或多个事件来表示更改，然后再将它们应用于它自己。这里的关键是事件的产生可以而且经常确实需要应用领域逻辑。换句话说，它不仅仅是一个事件制作者。

如果您觉得对您有帮助，我的博客上有一个典型 CQRS 应用程序的更详细概述。你可以在这里找到它：CQRS – A Step-by-Step Guide to the Flow of a typical Application