【发布时间】：2015-05-24 00:18:43
【问题描述】：
处理程序通常使用命令来修改聚合状态并发出事件，这些事件会持久保存到事件存储中。
但是根据今天的业务逻辑，我们可能会发出一些事件，而明天不会发出一些事件...... 我想知道这是否意味着命令也应该被持久化？您对此有何经验？
出于某些分析目的，恕我直言，查询可能会被持久化......
【问题讨论】：
标签： cqrs event-sourcing
【发布时间】：2015-05-24 00:18:43
【问题描述】：
这是个好问题。要记住的关键是事件源系统中的事件代表已经发生的事情。仅仅因为你在未来改变了逻辑并不会改变事件已经发生的事实。您需要考虑如何处理这些已弃用的事件。
您可以选择多种路线。一种可能性是为事件创建升级程序。您无需处理事件，而是通过升级过程运行它，从而有效地将其转换为下一个版本。另一种方法是在模型内进行升级工作。您甚至可能会发现在新系统中可以完全忽略它。
无论您决定做什么，要考虑的最重要的事情就是整个事件流。确保您所做的更改不会阻止您重新运行您的活动。不要破坏您的事件流！
在我写的一篇文章中，我对此有更深入的回应。你可以在这里找到它：How to Upgrade CQRS Events Without Busting Your Event Stream
希望对您有所帮助。
关于存储查询和命令的其他观点。您可以同时使用这两种方法，但是出于不同的原因，您需要小心处理它们。
除非您的整个系统基于 CQRS 和 ES，否则重新运行命令可能会失败，因为其他系统不同步。这不是事件流的问题。您还应该确保在命令中处理敏感信息。例如，它们可能包含未加密的信息，并期望在域内对其进行加密。
关于查询：CQRS 的驱动因素之一是平均业务线系统中的读写比率。如果您记录查询，则可能会影响性能，并且可能对存储空间的要求更高以处理数据的增长。
我发现记录命令和查询而不是仅仅存储它们很有用。通过这种方式，我可以了解最常运行的内容、持续时间和成功的历史。监控所有有用的健康统计数据。
无论如何，希望这会有所帮助。
【讨论】：
-
也许我误解了一些事情（我是这个主题的新手），但我认为你解决了一个不同的问题，当我的事件随着时间的推移而发生变化时，它的事件版本，我完全理解升级旧的概念版本并摆脱这个问题。在各种不同的演示文稿中，人们警告命令和事件源混淆......所以基本上当用户做某事时，我们有一个命令（或事件？）
-
我想我应该将它们视为事件，例如 CreateOrder (Command) 在进入业务逻辑或任何事件处理程序之前对我来说就像 OrderCreationInitiated (event) 这样我记录的初始来源修改...不是修改的结果...
-
据我了解，所有事件都可以分为两类，1. 从系统外部发起（例如由用户）和 2. 由业务逻辑发出（在未来的实现中可能会发生变化）因此只记录 2 不会是可靠的日志...
-
关键是如果业务逻辑发生变化并且不再发出某些事件（类型 2）然后事件流类型发生变化......因此我可能需要标记类型 1 和类型 2 evnets......这个正确吗？
-
考虑命令和事件的简单方法是：命令就是动作。改变状态的东西——不管在哪里或由谁发起。事件是代表状态变化的事物。请注意，这是状态更改而不是结果状态。将您的事件流视为仅附加。你永远不能回去改变一个事件。如果您有一个创建“错误”事件的错误，那么您发出补偿事件而不是删除或编辑旧事件。同样，如果您的系统不再发出特定事件，您不会返回并更改事件流。