事件采购命令与事件

Question

我理解命令和事件之间的区别,但在很多情况下,你最终会在2个基本相同的类之间进行冗余和映射(ThingNameUpdateCommand,ThingNameUpdatedEvent).对于这些简单的情况,您/您是否也可以将该事件用作命令？人们会将所有命令以及所有事件序列化到商店吗？对我来说似乎有点多余.

Answer 1

所有这些冗余都是出于某种原因,并且出于多种原因,您希望避免将相同的消息用于两个不同的目的:

1. 源事件必须在更改时进行版本控制,因为它们在存储时会被重新使用(反序列化),当您对聚合根进行水合时.如果该类也被用作消息,它将使事情有点尴尬.
2. 耦合增加,现在命令处理程序,域模型和事件处理程序使用相同的类.将命令侧与事件分离可以简化您的生活.
3. 最后清晰.命令以一种语言发布,该语言要求完成某些事情(通常是强制性的).事件代表了已经发生的事情(一般是过去时).如果你为两者使用相同的类,这种语言会变得混乱.

最后这些只是数据类,它不像是"硬"代码.有一些方法可以实际避免像code-gen这样的简单场景的某些类型.例如,我知道Greg已经使用XML和XSD转换来创建过去给定域所需的所有类.

我会说很多简单的情况你可能想要质疑这是真的域(即建模行为)还是只是数据.如果只是数据,请考虑不使用事件源.以下是Udi Dahan关于打破您的域名模型的演讲的链接,以便不是所有这些都需要事件源.我现在自己也很符合这种思维方式.

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

Answer 2

在完成了一些例子,特别是Greg Young的演讲(http://www.youtube.com/watch?v=JHGkaShoyNs)后,我得出的结论是命令是多余的.它们只是来自用户的事件,他们按下了那个按钮.您应该以与其他事件完全相同的方式存储它们,因为如果您希望在将来的视图中使用它,那么您将不知道这些数据.您的用户确实添加了,然后从篮子中删除该项目或至少尝试.您稍后可能希望使用此信息在以后提醒用户.