event-handling - 为什么在基于编排的 Sagas 中命令是必要的？

Question

EDA 中事件和命令之间经常强调的一个关键区别如下:

事件是已经发生的事情

命令是对可能发生的事情的请求

我不明白的是，为什么实现经常同时使用这两种方法，而其中一种似乎总是多余的？例如，当我们需要检查客户是否有足够的信用来完成订单时，我们可以纯粹通过事件来实现:

该图上没有任何命令。但在 this文章中，建议除了幕后事件之外还创建命令:

在这里还包含命令有什么好处，不是只会增加复杂性吗？客户服务实际订阅的是 CreatePendingOrderCommand 和 OrderCreatedEvent 这两者中的哪一个？客户服务肯定只执行其中一项吗？

Answer 1

What I can't understand is why implementations often use both of these together, when one always seems to be redundant?

一般来说，它们并不完全相同；只有在简单的情况下，信息才是冗余的。

“命令”类似于提案:它们是我们向某些权威机构发送的消息，以实现某些改变。 “事件”是从某个权威机构发送的消息。

命令向权威机构传递新信息。事件描述信息如何与之前已知的内容整合。

事件描述了处理 future 命令时可用的信息 - 该信息是持久的；命令是暂时的。

命令通常是根据某些信息(报告或“ View ”)的陈旧的非权威快照生成的。事件反射(reflect)了当局本身的状态。

事件从权威中散发出来；我们知道发送者，但不一定知道接收者。命令扇入权限，我们知道接收者，但不一定知道发送者。

它非常柔软。我们正在制作数据结构的副本，并且在某些时候我们的视角会发生变化，即使源数据结构是一个事件，副本也是一个命令。 p>

想想订阅:系统会将数据结构从我的输出流(事件)复制到您的输入流(命令)。

我的建议:这只是“消息”。让自己把它留在那里，直到你能跑更多圈。