为什么在基于编排的 Sagas 中需要命令？
Why are Commands necessary in choreography-based Sagas?
EDA 中 Events 和 Commands 之间经常强调的一个关键区别如下：
事件 是发生的事情
命令 是对可能发生的事情的请求
我不明白的是为什么在实现中经常同时使用这两者，而其中一个似乎总是多余的？例如，当我们需要检查客户是否有足够的信用来完成订单时，我们可以纯粹通过事件来实现：
此图上没有任何命令。但在 this 文章中，建议除了幕后事件外还创建了命令：
在这里也包括命令有什么好处，它不会增加复杂性吗？客户服务实际订阅的是 CreatePendingOrderCommand 还是 OrderCreatedEvent？客户服务肯定只对其中一项采取行动吗？
我会说
“一个命令可以发出任意数量的事件。”
“可以拒绝命令。”
“事件已经发生。”
What I can't understand is why implementations often use both of these together, when one always seems to be redundant?
总的来说，它们不是一回事；只有在简单的情况下，信息是多余的。
“命令”类似于提案：它们是我们发送给某些权威机构以实现某些改变的消息。 “事件”是从 某些权威机构发送的消息。
命令向权威机构传递新信息。事件描述了信息如何与之前已知的相结合。
事件描述了处理未来命令时可用的信息——信息是持久的；命令是暂时的。
命令通常是从某些信息（报告或“视图”）的陈旧非权威快照生成的。事件是权威本身状态的反映。
事件从权威中散开；我们知道发送者，但不一定知道接收者。命令范成一个权限，我们知道接收者，但不一定知道发送者。
它很软。我们正在复制数据结构，在某些时候我们的视角发生了变化，即使源数据结构是 event，副本也是 command.
思考订阅：系统将把数据结构从我的输出流（一个事件）复制到你的输入流（一个命令）。
我的建议：都是“消息”。让自己把它留在那里，直到你有更多的圈数。
EDA 中 Events 和 Commands 之间经常强调的一个关键区别如下：
事件 是发生的事情
命令 是对可能发生的事情的请求
我不明白的是为什么在实现中经常同时使用这两者，而其中一个似乎总是多余的？例如，当我们需要检查客户是否有足够的信用来完成订单时，我们可以纯粹通过事件来实现：
此图上没有任何命令。但在 this 文章中，建议除了幕后事件外还创建了命令：
在这里也包括命令有什么好处，它不会增加复杂性吗？客户服务实际订阅的是 CreatePendingOrderCommand 还是 OrderCreatedEvent？客户服务肯定只对其中一项采取行动吗？
我会说
“一个命令可以发出任意数量的事件。”
“可以拒绝命令。”
“事件已经发生。”
What I can't understand is why implementations often use both of these together, when one always seems to be redundant?
总的来说，它们不是一回事；只有在简单的情况下，信息是多余的。
“命令”类似于提案：它们是我们发送给某些权威机构以实现某些改变的消息。 “事件”是从 某些权威机构发送的消息。
命令向权威机构传递新信息。事件描述了信息如何与之前已知的相结合。
事件描述了处理未来命令时可用的信息——信息是持久的；命令是暂时的。
命令通常是从某些信息（报告或“视图”）的陈旧非权威快照生成的。事件是权威本身状态的反映。
事件从权威中散开；我们知道发送者，但不一定知道接收者。命令范成一个权限，我们知道接收者，但不一定知道发送者。
它很软。我们正在复制数据结构，在某些时候我们的视角发生了变化，即使源数据结构是 event，副本也是 command.
思考订阅：系统将把数据结构从我的输出流（一个事件）复制到你的输入流（一个命令）。
我的建议：都是“消息”。让自己把它留在那里，直到你有更多的圈数。