在 CQRS 中构造带有可选参数的命令对象

Question

我的Command 对象包含required 和optional 信息的组合，用于构造我的domain 对象。

class Command
{
  /*
  | Required stuff
  */
  private $req1;
  private $req2;

  /*
  | Optional stuff
  */
  private $opt1;
  private $opt2;
  private $opt4;

  private function __construct($req1, $req1, $opt1, $opt2, $opt3)
  {
    $this->setReq1($req1);
    // ...
  }
}

对于具有大量参数（必需和/或可选）的对象，您可以使用builder pattern 而不是冗长的构造函数。我可以为我的command 使用builder，但是，我不确定这是正确的方法吗？

builder pattern 在这里是否合适，或者我应该将command 简化为更像DTO（公共属性）并在command handler 中执行validation？还是有其他选择？

Answer 1

对于具有大量参数（必需和/或可选）的对象，您可以使用构建器模式，而不是使用冗长的构造器。我可以为我的命令使用构建器，但是，我不确定这是正确的方法吗？

您可能应该像对待 message 一样考虑 command。

消息构建器是一种方便的模式，用于将消费者与消息中可选参数的详细信息隔离开来——您的构建器可以与客户端不需要知道的合理默认值打包在一起。

请注意，这是与构造的属性应该是公共的还是私有的正交的问题；一旦您决定消息的属性是不可变的，那么公共与私有在很大程度上就变成了您是否需要将消费者与可能的基础数据重新安排隔离开来的问题。

不确定您所说的以对待消息的方式思考命令是什么意思？

真正的命令对象是：传递给模型的输入在内存中的表示。

常见情况：用户提交表单，通过http请求传输。有效负载（在一个抽象级别上，只是一个字节数组）被赋予特定领域的解释。通常，我们的应用层封装/转换字节数组，并将其传递给领域模型——领域模型从不看到“字节”，而是看到“值”。

但语义是消息的；特别是，如果命令的原始源和域模型是可独立部署的——旧客户端尝试将命令发送到新模型，新客户端尝试将命令发送到旧模型等等，您会遇到各种兼容性问题。

处理这些问题的一种方法是将命令视为弱架构消息；许多可选字段，如果缺少可选值，则采用默认值。 Builder 模式非常适合这种方法——构建器知道所有默认值，并跟踪客户端提供了对默认值的覆盖的情况。