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

Question

据推测，我们可以通过应用同一组命令来恢复状态，那么为什么不简单地存储命令而不是事件呢？

Answer 1

事件，沟通“这发生在我们的系统中”。接受并处理命令时会发生事件。没有人可以拒绝或改变它发生的事实。它是系统中唯一权威的变更来源

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

。

Answer 2

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

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

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

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

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

结论：命令= CommandGivenEvents，“事件” = BusinessLogicProcessedAndStoredEvents。目的不同。就像您如何更改事件处理程序一样，预计的数据也会有所不同。如果更改业务逻辑，则命令将产生不同的事件流。再上一步。