Domain driven design 在DDD中，命令是否严格同步API调用？

当我在DDD上下文中阅读有关命令时，它通常被描述为一个API调用

在本例中，serviceA向serviceB发送命令

serviceA->serviceB

在我的理解中，指挥是一种具体的行动。所以从技术上讲，这也可以是异步的。可能在消息队列中发送命令消息

serviceA->queue->serviceB

---

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

域驱动设计环境中的命令：

在域驱动设计的上下文中，命令表示系统中发生某件事的意图，该意图在执行后导致某种预期结果。因此，可以将其视为包含命令接收者执行命令所需的所有信息的对象

因此，当谈到域驱动设计中的命令时，在触发和传输命令的方式，或所需信息的表示方式方面没有技术定义或限制

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

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

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

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

• 在网上商店中签出当前购物篮以启动订单
• 向上投票并回答stackoverflow，增加答案的投票数

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

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

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

TL；DR

回到你的问题：

当我在DDD上下文中阅读有关命令时，它通常被描述为一个API调用

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

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

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

当然，它也可以是异步的