事件溯源命令与事件答案

【问题标题】：Event Sourcing Commands vs Events事件溯源命令与事件
【发布时间】：2011-07-13 14:01:25
【问题描述】：

我了解命令和事件之间的区别，但在很多情况下，您最终会在两个基本相同的类（ThingNameUpdateCommand、ThingNameUpdatedEvent）之间产生冗余和映射。对于这些简单的情况，您/您是否也可以将事件用作命令？人们是否将所有命令和所有事件都序列化到存储中？对我来说似乎有点多余。

【问题讨论】：

标签： cqrs event-sourcing

【解决方案1】：

所有这种冗余通常是有原因的，出于多种原因，您希望避免将同一消息用于两种不同的目的：

当源事件发生变化时，必须对其进行版本控制，因为当您对聚合根进行水合时，它们会被存储和重新使用（反序列化）。如果这个类也被用作消息，那会让事情变得有点尴尬。
增加了耦合，命令处理程序、域模型和事件处理程序现在使用相同的类。将指挥方与事件分离可以简化您今后的生活。
终于清晰了。命令以要求完成某事的语言发出（通常是命令式）。事件是已经发生的事情的表示（通常是过去时）。如果您对两者使用相同的类，这种语言就会变得混乱。

最后，这些只是数据类，而不是“硬”代码。对于像代码生成这样的简单场景，有一些方法可以实际避免一些打字。例如，我知道 Greg 过去曾使用 XML 和 XSD 转换来创建给定域所需的所有类。

我想说，对于很多简单的案例，您可能想质疑这是否真的是领域（即建模行为）或只是数据。如果只是数据，请考虑在此处不使用事件溯源。下面是 Udi Dahan 的演讲链接，该演讲关于分解您的领域模型，以便并非所有这些都需要事件溯源。我自己现在有点符合这种思维方式。

http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan

【讨论】：

【解决方案2】：

在研究了一些示例，尤其是 Greg Young 的演示文稿 (http://www.youtube.com/watch?v=JHGkaShoyNs) 之后，我得出的结论是命令是多余的。它们只是来自您的用户的事件，他们确实按下了该按钮。您应该以与其他事件完全相同的方式存储这些数据，因为它是您不知道是否要在将来的视图中使用它的数据。您的用户确实添加了该项目，然后从篮子中删除了该项目，或者至少尝试这样做。您以后可能希望使用此信息来提醒用户这一点。

【讨论】：

我也倾向于这个方向。我读到了一些关于您希望您的事件包含完成工作所需的所有数据的观点，尤其是当这些数据可能来自没有历史表示的外部系统时。但是您也可以简单地将这种良好实践应用于命令。特别是我认为，如果你想做一些非常 DDD 的东西，命令或事件之间不应该有真正的区别。意图应该是明确的，并且应该包含域外的历史数据。
我仍然认为命令是多余的。我只是把我所做的事情称为功能性事件溯源。我最近的一篇博客，将 ES 和 F# Elm 作为一个完整的系统：anthonylloyd.github.io/blog/2016/11/27/event-sourcing
我也认为我的不同之处在于使用 FP 而不是 OO。 ES 非常好地映射到 FP，sum 类型是一种自然可扩展的事件模式。不变性也非常适合 ES。
我认为用户命令也可以被视为事件的另一个原因是因为我将 UI 设计为具有已修改的本地数据，并且这些修改作为命令/事件异步发送到后端，并且事后。你会想假设一切顺利，如果没有，就做出适当的回应。换句话说，我目前在想，没有真正的区别。
看看这个项目 - github.com/gregoryyoung/m-r 。它同时使用命令和事件。