-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Command bus и CQRS
- Автор темы Adelf
- Дата начала
Вурдалак
Продвинутый новичок
Ошибочно полагать, что CQRS — это какое-то «расширение» CQS. Эти два слова только и роднит, что общее название. CQRS про модели, CQS про методы. Метод у command bus вполне может что-то возвращать, те же события. Некая идея о разделении «команд» и «запросов» роднит на очень далеком уровне. Под «командами» и «запросами» тут понимаются очень разные вещи.
да понятно что это не расширение. Я о том что в качестве примеров и в качестве более менее стандартных реализациях CQRS используются именно пары команда-хандлер, как результат инициализация громоздкая, да и много классов если применять как в примерах к библиотекам. Я чисто с технической стороны описания команды, а не о том какие модели будут использоваться под капотом.
Я правильно понимаю, что есть только один класс команды куда передается контекст (в котором параметры для хандлеров) и id команды и команда может вернуть объект результата выполнения хандлеров и/или содержать массив ошибок их выполнения (типа $command->erros и т.д.)?
Последнее редактирование:
Просто я вот думаю я правильно понял @Вурдалак насчет единой команды, куда параметры команды передаются через контекст, и с добавлением уникального команд ид или нет. И использует еще кто-то такое или нет. Просто такой подход значительно уменьшает количество почти идентичных классов команд, но я не уверен что правильно понял
@fixxxer А такая идея имеет право на существование?
Т.к. в большинстве случаев у команды только 1 хандлер, объединять команду с хандлером в один класс, с возможностью добавления других хандлеров. Да я в курсе насчет нарушения SRP, но создавать отдельный класс из пары строк только для описания параметров - как-то перебор и явно не лучший код. Или использовать анонимный класс для команды.
Т.к. в большинстве случаев у команды только 1 хандлер, объединять команду с хандлером в один класс, с возможностью добавления других хандлеров. Да я в курсе насчет нарушения SRP, но создавать отдельный класс из пары строк только для описания параметров - как-то перебор и явно не лучший код. Или использовать анонимный класс для команды.
@Yoskaldyr боязнь создания новых классов загубила немало кода.
Не надо бояться. Это вполне нормальная вещь для объектно-ориентированного программирования
Не надо бояться. Это вполне нормальная вещь для объектно-ориентированного программирования
только проблема в том что dto-шки используются часто, а команда в 1 месте и все (в 99% случаев). Т.е. отдельная dto-шка только для единоразового использования - значит что-то не так с этой dto-шкой и передать данный можно было как-то иначе.
P.S. Да сюда прямо просятся анонимные классы, но только как самый последний вариант.
P.S. Да сюда прямо просятся анонимные классы, но только как самый последний вариант.
откуда такой вывод?
уточняю. я имею ввиду дто-шку для передачи данных не просто в пределах одного слоя (а не между слоями), а в пределах одного класса.
Т.е. это полный аналог, если писать
вместо более простой версии
Какой сакральный смысл в такой дто-шке? Только для обмазывания паттернами?
Т.е. это полный аналог, если писать
PHP:
class SomeUser {
// и конструктор присвающий эти значения, лень писать
public $name;
public $email;
}
//.....
class SomeClass {
public function someMethod () {
// создание этого класса только в этом месте и все, больше нигде в коде встречаться не будет
$user = new SomeUser ('User Name', '[email protected]');
$this->userMethod($user);
}
public function userMethod (SomeUser $user) {
// делаем что-то в почтой и именем
// но метод вызывается и используется только один раз в $this->someMethod и это 100% известно что не будет меняться
}
}
PHP:
class SomeClass {
public function someMethod () {
$this->userMethod('User Name', '[email protected]');
}
public function userMethod ($name, $email) {
// делаем что-то в почтой и именем
// но метод вызывается и используется только один раз в $this->someMethod и это 100% известно что не будет меняться
}
}
Последнее редактирование:
этот пример вообще непонятен. я думал мы говорим про Command классы в контексте Command bus.
Data Transfer Object. дтошки делаются для трансфера данных куда-то. например эту команду могут послать выполнить не сразу, а в очереди. абстракция комманд баса дает некоторые преимущества...
Data Transfer Object. дтошки делаются для трансфера данных куда-то. например эту команду могут послать выполнить не сразу, а в очереди. абстракция комманд баса дает некоторые преимущества...
Я то понимаю все плюсы, проблема в том что когда известны поставленные задачи и заранее известно, что 90% всех команд будут из команды и одного хандлера и никаких отложенных выполнений, никаких очередей и т.д. А остальные 10% будут для добавления дополнительного логирования через еще один дополнительный хандлер. Все.
Зачем заранее усложнять если ничего сложного заранее известно что не будет?
Последнее редактирование:
Еще раз попытаюсь объяснить. У меня куча команд с разными параметрами. Но 90% из них это команды из одного хандлера, который используется только в этой конкретной команде.
Я понимаю все преимущества небольшого класса команды (дто) в комманд басе - можно хранить, сериализировать передавать на другие микросервисы и т.д.
Но если этого не будет и в принципе не может быть исходя из поставленных задач и если почти всегда только один уникальный командхандлер на конкретную команду. Тогда зачем делать
PHP:
(new SomeCommand($param1, $param2))->registerHandler(new SomeCommandHandler())->exec();
PHP:
(new SomeCommandWithIncludedHandler($param1, $param2))->exec();
PHP:
(new SomeCommandWithIncludedHandler($param1, $param2))->registerHandler(new SomeCommandSecondHandler())->exec();