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

Question

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

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

服务A -> 服务B

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

服务A -> 队列 -> 服务B

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

Answer 1

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

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

因此，当在领域驱动设计中谈论命令时，没有技术定义或限制命令可以被触发和传输或者如何表示所需信息。。

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

命令可以被触发/传输，例如，可以通过以下方式:

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

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

• 在网上商店中查看当前的购物篮以发起订单
• 在 stackoverflow 上投票和回答，并增加答案的投票

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

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

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

TL;DR

回到你的问题:

When I read about Command in the DDD Context, it is usually described as an API call.

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

Are Commands strictly synchronous API calls, or can be asynchronous?

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

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