design-patterns - CQRS:命令返回值

Question

关闭。这个问题是 opinion-based 。它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。

2年前关闭。



Improve this question




关于命令是否应该有返回值似乎是无休止的混淆。我想知道混淆是否仅仅是因为参与者没有说明他们的背景或情况。
困惑
以下是混淆的例子......

Udi Dahan 说命令“不会向客户端返回错误”，但 in the same article 他展示了一个图表，其中命令确实向客户端返回错误。

Microsoft Press Store 的一篇文章指出“该命令......不返回响应”，但随后给出了一个模棱两可的警告:

As battlefield experience grows around CQRS, some practices consolidate and tend to become best practices. Partly contrary to what we just stated... it is a common view today to think that both the command handler and the application need to know how the transactional operation went. Results must be known...

Jimmy Bogard 说“commands always have a result ”，但随后又努力展示命令如何返回无效。

那么，命令处理程序是否返回值？
答案？
从 Jimmy Bogard 的“ CQRS Myths ”中得到提示，我认为这个问题的答案取决于您所说的程序化/上下文“象限”:

+-------------+-------------------------+-----------------+
|             | Real-time, Synchronous  |  Queued, Async  |
+-------------+-------------------------+-----------------+
| Acceptance  | Exception/return-value* | <see below>     |
| Fulfillment | return-value            | n/a             |
+-------------+-------------------------+-----------------+

验收(例如验证)
命令“接受”主要是指验证。据推测，验证结果必须同步提供给调用者，无论命令“履行”是同步的还是排队的。
但是，似乎许多从业者不会从命令处理程序内部启动验证。从我所见，要么是因为 (1) 他们已经找到了一种在应用层处理验证的绝妙方法(即 ASP.NET MVC Controller 通过数据注释检查有效状态)或​​ (2) 架构假设命令已提交到(进程外)总线或队列。后面这些异步形式通常不提供同步验证语义或接口(interface)。
简而言之，许多设计人员可能希望命令处理程序将验证结果作为(同步)返回值提供，但他们必须忍受他们正在使用的异步工具的限制。
履行
关于命令的“执行”，发出命令的客户端可能需要知道新创建记录的 scope_identity 或失败信息 - 例如“帐户 overdraw ”。
在实时设置中，返回值似乎最有意义；异常不应用于传达与业务相关的失败结果。但是，在“排队”上下文中……返回值自然没有意义。
这就是所有困惑可能总结的地方:

Many (most?) CQRS practitioners assume they will now, or in the future, incorporate an asynchrony framework or platform (a bus or queue) and thus proclaim that command handlers do not have return values. However, some practitioners have no intention of using such event-driven constructs, and so they will endorse command handlers that (synchronously) return values.

因此，例如，我相信在 Jimmy Bogard provided this sample command interface 时假定了同步(请求-响应)上下文:

public interface ICommand<out TResult> { }

public interface ICommandHandler<in TCommand, out TResult>
    where TCommand : ICommand<TResult>
{
    TResult Handle(TCommand command);
}

毕竟，他的 Mediatr 产品是一种内存工具。鉴于所有这些，我认为 Jimmy carefully took the time to produce a void return from a command 的原因不是因为“命令处理程序不应该有返回值”，而是因为他只是希望他的 Mediator 类具有一致的接口(interface):

public interface IMediator
{
    TResponse Request<TResponse>(IQuery<TResponse> query);
    TResult Send<TResult>(ICommand<TResult> query);  //This is the signature in question.
}

...即使并非所有命令都有有意义的返回值。
重复和总结
我是否正确地捕捉到了为什么在这个主题上存在混淆？有什么我想念的吗？
更新 (6/2020)
在给出的答案的帮助下，我想我已经解开了困惑。简而言之，如果 CQRS 命令能够返回指示完成状态的成功/失败，则返回值是有意义的。这包括返回一个新的 DB 行标识，或任何不读取或返回域模型(业务)内容的结果。
我认为“CQRS 命令”混淆出现的地方在于“异步”的定义和作用。 “基于任务”的异步 IO 和异步架构(例如基于队列的中间件)之间存在很大差异。在前者中，异步“任务”可以并将提供异步命令的完成结果。但是，发送到 RabbitMQ 的命令不会类似地收到请求/响应完成通知。正是异步架构的后一种上下文导致一些人说“没有异步命令这样的东西”或“命令不返回值”。

Answer 1

按照 Vladik Khononov 在 Tackling Complexity in CQRS 中的建议，命令处理可以返回与其结果相关的信息。

Without violating any [CQRS] principles, a command can safely return the following data:

• Execution result: success or failure;
• Error messages or validation errors, in case of a failure;
• The aggregate’s new version number, in case of success;

This information will dramatically improve the user experience of your system, because:

• You don’t have to poll an external source for command execution result, you have it right away. It becomes trivial to validate commands, and to return error messages.
• If you want to refresh the displayed data, you can use the aggregate’s new version to determine whether the view model reflects the executed command or not. No more displaying stale data.

Daniel Whittaker 提倡从包含此信息的命令处理程序返回一个“ common result”对象。