在 Event Store / CQRS 架构中，为什么存储事件而不是命令？答案

【问题标题】：In Event Store / CQRS architecture, why are events stored instead of commands?在 Event Store / CQRS 架构中，为什么存储事件而不是命令？
【发布时间】：2020-10-27 17:48:36
【问题描述】：

假设我们可以通过应用相同的命令集来恢复状态，那么为什么不简单地存储命令而不是事件呢？

【问题讨论】：

标签： cqrs event-sourcing

【解决方案1】：

事件，传达“这发生在我们的系统中”。当命令被接受和处理时发生事件。没有人可以拒绝或改变它发生的事实。它是系统变化的唯一权威来源

命令只是系统的一部分（如 UI）告诉负责对系统进行更改的组件（“命令处理程序”）它想要做什么的一种方式。但是，命令处理程序可以出于各种原因选择不处理该命令。 UI 可能有陈旧的信息，处理命令没有商业意义，或者用户可能没有执行该操作的权限。无论哪种方式，该命令实际上只是一个请求，与系统状态无关

。

【讨论】：

谢谢，很有帮助。
另外，重新执行命令将是破坏性的（影响数据）。要重新执行命令才能正常工作，您必须具有相同的初始状态。根据定义，事件不是破坏性的。
我知道我参加聚会有点晚了，但事件存储的全部意义不在于重新创建应用程序状态吗？命令的请求本身不就是一个事件吗？
@Fatmuemoo 没有命令是要执行的。事件是发生的事情。当我们处理命令时，会发生业务逻辑，以便创建事件。事件被处理，然后我们做出我们的预测。命令 = 要发生的事情，事件 = 已经发生的事情。如果我们要存储事件并“回复它们”，如果我们更改业务逻辑，结果事件可能会完全不同。如果我们想改变我们的项目（当前状态/模型），我们绝对可以这样做，但我们通过重播事件来做到这一点。已经发生的事情无法改变
@Matster2 为什么我们不能接受命令，验证它，只有当它有效时，才将它存储在流中？如果它存储在流中，那么它就变成了一个事实（事件）。

【解决方案2】：

您的应用可以处理“命令流”以产生“事件流”，从而产生“当前数据”。

当然可以存储命令，但问题是你为什么要这样做？

一些可能的答案包括，命令本身就是有用的数据。您可能想知道用户尝试将商品添加到购物车的次数（命令），即使购物车已满后不再添加商品（事件）。当然，这可以通过另一个事件来解决，可能名为“尽管购物车已满，但已添加物品”

因此，命令就是事件。您使用业务逻辑对其进行处理以产生另一个事件流，我们将它们称为状态事件。您可以创建另一个流，或投影到关系数据结构上，或其他任何东西。添加命令可能会增加复杂性，这有利于更多数据。就像事件溯源本身比传统的“当前状态”数据存储高出一步一样。

编辑：以上内容清除了术语和目的。

结论：Commands = CommandGivenEvents，“事件” = BusinessLogicProcessedAndStoredEvents。不同的目的。就像如果您更改事件处理程序一样，投影数据将有所不同。如果您更改业务逻辑，命令将产生不同的事件流。更上一层楼。

【讨论】：