CQRS 命令 - DTO答案

【问题标题】：CQRS Command - DTOCQRS 命令 - DTO
【发布时间】：2020-11-22 16:58:24
【问题描述】：

我学习了一段时间的 CQRS 和 DDD。我的问题是如何管理命令。特别是命令，因为命令可能比查询更复杂。如何使用嵌套的 dto 编写命令？

【问题讨论】：

我看不到命令和 DTO 之间的关系。您能否更准确地说明您要实现的目标？
@Manel，让我们认为我们必须创造产品。同样的命令我们必须创建相关的产品类型。我该如何设计我的命令？这是两张不同的桌子
也许你应该看看如何设计一个事件溯源/cqrs 系统。我不认为 stackoverflow 适合涵盖如此广泛的主题。
快速恢复：命令 -> 可以写入事件 -> 可以在读取数据库 (cqrs) 中进行投影。您的投影必须包含前端视图所需的所有数据。
@Manel，不，我的问题是设计命令。在正常的应用程序不是 cqrs 我们编写嵌套 dto（产品 dto 保持产品类型 dto）我们如何编写创建产品并创建产品类型的命令？

标签： domain-driven-design cqrs dto clean-architecture

【解决方案1】：

您要做的第一件事是定义您的领域模型。当您使用 DDD 时，可以更好地应用 CQRS。现在不要考虑持久性机制（例如您的数据库）。令人惊讶的是，这几乎会变成一个“实现细节”。

命令应该只包含系统执行手头操作所需的最少信息。例如，让我们想象一个“创建客户”命令。它将公开姓名、电子邮件和客户 ID。 Command 实例必须是不可变的：一旦初始化，就无法更改。命令处理程序接收命令实例，根据业务不变量对其进行验证，如果一切正常，则保留数据。命令处理程序不返回数据，它们是“一劳永逸”。

通常，对于 CQRS，有 2 个不同的持久性存储，一个用于 Write 端，另一个用于 Read 端。首先专注于您的写作。

【讨论】：

你从哪里读到命令是“一劳永逸”？命令是请求-响应模型，事件是“一劳永逸”的，因为你不知道谁会使用它们。
@JoãoAntunes 在异步执行的频繁情况下（例如，命令处理程序将消息发送到队列），并没有真正需要返回结果。域操作将在其他地方处理，因此命令处理程序不需要返回值。现在，我们可以考虑另外两件事：命令验证和瞬态异常。验证应该在命令执行之前进行。当发送到处理程序时，命令应该始终有效。可能会发生暂时性异常（例如网络问题），并且必须冒泡到有效的异常管理器。
如果是同步执行，我想可能会有一个值返回某种“成功/失败”结果。但老实说，这种情况非常罕见。
在异步执行中，当您发送命令时，您可以跟踪该命令的进度，如果您返回 OperationStateId，则操作应该跟踪该命令的进度。您可以稍后确认该命令是否成功执行，并正确处理错误。