我想总结一下我对CQRS / ES的了解 . 我不久前开始阅读这个主题，因为我是年轻的开发人员，我不理解这个概念的每个方面 . 我将尝试在一些示例流程中描述我对CQRS的理解 . 因此，定义该架构的一般步骤，我们遵循以下流程：
-
用户向我们的控制器发出请求 . 在该控制器方法中，我们创建指定的 Command （例如 CreateOrder ）并将其传递给 Handler .
-
全局消息总线（或处理程序）负责将命令路由到指定的命令处理程序 . 所以在这里我们将命令传递给 CreateOrderHandler
-
在处理程序中，我们创建 Aggregate root （在本例中为 OrderAggregate ），我们应用 EventStore 中的所有事件 . 在EventStore中，我们只保留与指定聚合相关的事件数据（由全局id定义） . 所以在这一步之后我们在当前状态下聚合 .
-
当我们创建聚合时，我们传递给它我们的命令和方法我们werify如果命令可以执行 . 如果我们可以运行此命令，我们创建 Event （在本例中为 OrderCreated ） .
-
如果没有任何异常我们在EventStore中保存了事件（我认为使用NoSql DB和简单的保存事件很简单）
-
现在处理程序将保存的事件传递给我们的 Denormalizer 类，该类是创建 View Models 的网关 . 因此，如果denormalizer获得一些事件，它会在我们的应用程序中更新/创建所有ViewModel . 我们将ViewModel保存在单独的DB中 .
-
用户可以查询更新的视图模型 .
所以我这是我对CQRS / ES理解的简化版 . 请在每一层都纠正我 . 我的问题是：
在第4步中我们创建聚合应该在DB中保存这个聚合吗？保持现状 . 我在这里错过了什么吗？我们创建聚合只是为了检查创建事件的可能性？
我应该有实体吗？如果我在第5步中正确，我可以更新聚合实体并在我的视图模型中使用它们 . 我在这里有最大的困惑 .
谢谢你的所有答案;）
2 回答
如果您使用EventStore，则ES本身会保留聚合的状态 . 你在命令处理程序中谈论“创建”聚合，但通常最好说在命令处理程序中聚合从ES重新补充 .
Aggregate使用在ES中应用的命令（或其数据）和引发（域）事件来跟踪聚合的状态更改，并且事件处理程序（如denormalizer）处理相同的事件 .
在通常描述的流程中，我在步骤3之前进行了命令验证步骤 . 无论如何，前段时间我试图描绘components of a typical CQRS/ES flow;网上有几个，但也许它可能有用
聚合状态源自应用于它的过去事件 . 因此，您不需要存储它的状态，因为它是从事件流派生的 . 说过你可能想要创建快照以避免很长的事件历史记录 . 在设计快照系统之前，值得测试重新应用先前事件列表的速度 .
当您向聚合发出命令时，它会分两个阶段处理它 . 第一阶段基本上检查它可以运行 . 如果是这样的话，它会构建一个或多个事件来表示变化，然后再将它们应用到自身 . 关键在于事件的产生可以并且经常需要域逻辑的应用 . 换句话说，它不仅仅是一个事件制作者 .
如果您发现它有用，我会在我的博客上详细介绍典型的CQRS应用程序 . 你可以在这里找到它：CQRS – A Step-by-Step Guide to the Flow of a typical Application