Event handling 为什么在基于编舞的传奇中命令是必要的？

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

事件是已经发生的事情

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

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

此图表上没有任何命令。但在本文中，建议在幕后事件之外创建一些命令：

在这里也包含命令有什么好处，不是增加了复杂性吗？客户服务实际订阅的是哪一个，CreatePendingOrder命令，还是OrderCreated事件？肯定只有一个是由客户服务部执行的吗？

我想说

“命令可以发出任意数量的事件。”

“可以拒绝命令。”

“事情已经发生了。”

我不明白的是，为什么实现经常同时使用这两种方法，而其中一种似乎总是多余的

总的来说，它们不是完全一样的东西；只有在简单的情况下，信息才是多余的

“命令”是一种类似于提议的东西：它们是我们向某个权威发出的信息，以实现某种改变。“事件”是从某个机构发送的消息

命令将新信息传递给权限。事件描述了信息是如何与以前已知的信息集成的

事件描述在处理未来命令时可用的信息-信息是持久的；命令是暂时的

命令通常是从某些信息（报表或“视图”）的过时的非授权快照生成的。事件是当局自身状态的反映

事件从一个权威机构散开；我们知道发送者，但不一定知道接收者。命令变成了权威，我们知道接收者，但不一定知道发送者

它很粘。我们正在复制一个数据结构，在某一点上，我们的视角发生了变化，尽管源数据结构是一个事件，但复制是一个命令

思考订阅：系统将把数据结构从我的输出流（一个事件）复制到你的输入流（一个命令）

我的建议是：这些都只是“信息”。允许您将其留在那里，直到您的腰带下有更多圈数。

一个命令可以发出任意数量的事件-一个命令就是DTO。它不能发射任何东西。