我对CQRS和事件溯源都很陌生，希望有人能够帮助我。
简而言之：我接收一个命令对象并将其传递给类似聚合根的东西。聚合根生成一个事件，该事件存储在存储库中。现在我可以使用此事件来重建聚合根到当前状态。这样正确吗？
现在考虑一下我的想法：保存命令是否更容易？如果我有一个create-command和五个update-command，我可以通过在空聚合上执行六个命令来重建我的聚合。我不需要处理命令和事件来生成聚合根。
事件也可以用作领域事件，但我不需要它们进行事件溯源。
与我的方法相比，使用事件溯源有什么优势？
好问题。有几个原因。我将仅涵盖其中两个。第一个更为概念化，第二个则更具体。
从概念上讲，您正在存储由于命令而发生的更改。实际发生了什么。随着应用程序在其生命周期中的不断发展，您可能会改变如何处理命令。您甚至可能会更改所创建的事件。因此，如果只有命令，则无法保证能够恢复聚合的状态。
如果您需要重播事件，也会遇到问题。假设您需要基于过去的事件创建新的读取模型。但是如果您没有它们，就无法完成这项任务。另外，在重建聚合或创建新的读取模型时，您不希望系统实际执行所有命令使其执行的事情。例如，假设在特定命令的正常处理过程中发送了电子邮件。您不希望每次重建聚合时都发送该电子邮件。
希望这样说得清楚。
此外，请注意“create”“read”update”命令。这听起来像是代码异味。请查看https://danielwhittaker.me/2014/10/18/6-code-smells-cqrs-events-avoid/
我不会回答事件溯源的优势是什么，但我认为重要的是考虑你想要实现什么，命令来自哪里以及何时需要存储命令以及事件。
你想要实现什么？ 如果你想将你的服务版本1.0接收到的所有命令应用于新开发的版本1.1中，那么你就需要这些命令。例如，你可以这样做来测试服务的功能或性能。
命令来自哪里？ 命令是基于事件创建的，由UI、其他不发布事件的应用程序创建等。
何时需要存储命令以及事件？ 如果目标是模拟与生产环境相同的环境，则需要记录所有输入。因此，你需要所有命令。如果你不存储来自UI的命令，那么你就没有这些命令。因此，如果没有生成命令的事件或者你没有存储它，存储命令可能是有优势的。为了保持一致性，你可以存储一个包含命令和请求中的附加数据的HttpRequestReceivedEvent，而不是存储ChangeUserCommand。
