Построение командного объекта с необязательными параметрами в CQRS

Question

Построение командного объекта с необязательными параметрами в CQRS

мой 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 вместо того, чтобы иметь длинные конструкторы. Я мог бы использовать builder для меня commandОднако я не уверен, что это правильный подход?

Это builder pattern здесь уместно или я должен упростить command чтобы быть более DTO как (публичные атрибуты) и выполнить validation в command handler? Или есть другой вариант?

0

builder-pattern cqrs design-patterns domain-driven-design php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Для объектов, которые имеют большое количество параметров (обязательных и / или необязательных), вы можете использовать шаблон построителя, а не иметь длинные конструкторы. Я мог бы использовать строитель для моей команды, однако, я не уверен, что это правильный подход?

Вы, вероятно, должны подумать о command как вы делаете message,

Построители сообщений являются удобным шаблоном для изоляции потребителей от деталей необязательных параметров в сообщении — ваш компоновщик может поставляться с разумными значениями по умолчанию, о которых клиентам не нужно знать.

Обратите внимание, что это ортогональный вопрос о том, должны ли построенные свойства быть открытыми или закрытыми; как только вы решили, что свойства сообщения являются неизменяемыми, общедоступные и частные в основном становятся вопросом о том, нужно ли вам изолировать потребителей от возможных перестановок базовых данных.

Не уверен, что вы имеете в виду, когда говорите, думайте о команде так же, как и о сообщении?

Что на самом деле является командным объектом: представление в памяти входных данных, передаваемых в модель.

Распространенный случай: пользователь отправляет форму, которая передается через http-запрос. Полезная нагрузка (которая на одном уровне абстракции является просто байтовым массивом) дается для конкретной предметной интерпретации. Как правило, наш прикладной уровень упаковывает / конвертирует байтовый массив и передает его в модель предметной области — модель предметной области никогда не видит «байты», а скорее «значения».

Но семантика те из сообщение; в частности, у вас возникают различные проблемы совместимости, если исходный источник команды и модель домена могут быть развертываемы независимо — старые клиенты пытаются отправлять команды новым моделям, новые клиенты пытаются отправлять команды старым моделям и т. д.

Один из подходов к решению этих проблем состоит в том, чтобы рассматривать команду как сообщение со слабой схемой; много необязательных полей, со значениями по умолчанию, которые должны быть приняты, если необязательное значение отсутствует. строитель шаблон является естественным подходом для этого подхода — сборщик знает все значения по умолчанию, отслеживает те случаи, когда клиент предоставил переопределение значения по умолчанию.

0