在 DDD 中，命令是严格同步的 API 调用吗？

Question

当我在 DDD 上下文中阅读有关 Command 的内容时，它通常被描述为 API 调用。

在此示例中，serviceA 向 serviceB 发送命令。

serviceA -> serviceB

在我的理解中，命令是对某件事的具体行动。因此从技术上讲，这也可以采用异步形式。也许在消息队列中发送命令消息。

serviceA -> queue -> serviceB

命令是严格同步的 API 调用，还是可以是异步的？

Answer 1

领域驱动设计上下文中的命令：

命令 - 在领域驱动设计的背景下 - 代表系统中发生某些事情的意图，这些事情在执行后会产生一些期望的结果。因此它可以被看作是某个对象，其中包含命令接收者执行命令所需的所有信息。

因此，当谈论领域驱动设计中的命令时，不存在以何种方式触发和传输命令或如何表示所需信息的技术定义或限制。

命令应该首先从业务角度进行描述，以找出系统上下文中的什么或谁会触发它以及何时触发。以及命令执行后的预期状态。

可以通过以下方式触发/传输命令：

• 当用户单击网站上的按钮时执行一些同步 REST 请求
• 发送异步消息（例如从一个微服务）到命令接收者（例如另一个微服务）的消息队列
• 执行 gRPC 调用（例如从一个微服务到另一个微服务）
• 单击桌面应用程序 UI 中的按钮
• 执行预定的后台任务

例如，业务上下文中的命令可以是：

• 在网上商店结账当前购物篮以发起订单
• 在 stackoverflow 上点赞和回答并增加答案的投票

在领域驱动设计的上下文中，如果命令是同步执行还是异步执行，则只是一些实现细节。重要的是，在执行成功后，预期的结果就会发生。

执行同步 API 调用时，如果命令执行正常，触发命令的组件可以通过同步应答获得反馈。

而在异步命令传输（如消息传递）中，您只会知道消息已传递到某个队列，但必须以其他方式感知命令的成功执行。通过查询所涉及的域实体的当前状态，或者利用某种基于事件的机制，在执行命令后发布事件，并且任何感兴趣的各方都可以订阅这些事件。

长话短说

回到你的问题：

当我在 DDD 上下文中阅读有关 Command 的内容时，它通常被描述为 API 调用。

API调用本身只是命令的技术数据表示和传输。

命令是严格同步的 API 调用，还是可以是异步的？

相同的命令可以以不同的方式触发（参见前面的示例）并以不同的方式再次传输。但无论如何触发或如何传输，它都必须包含相同的所需信息，并且在执行后将在整个系统中产生相同的期望结果。

所以，是的，它当然也可以是异步的。