Command bus и CQRS

fixxxer

К.О.
Партнер клуба
Выглядит как попытка сэкономить на написании пары символов.
Я, конечно, предпочел бы вариант с передачей value objects - хотя бы потому, что они могут понадобиться и в другой команде (один HTTP-запрос запросто может приводить к выполнению нескольких команд, почему бы и нет).
Но, в принципе, в данном конкретном случае никакого особого вреда, кроме неявности выбрасываемого исключения, не вижу.
 

alexion

Новичок
А почему никто не передает сущность, вместо VO? В чем могут быть подводные камни сделать так?
PHP:
class CreateCommentCommand
{
    private User $author;
    private Text $text;
    
    public function __construct(User $author, Text $text)
    {
        $this->author = $author;
        $this->text = $text;
    }
}
У нас же уже прошла аутентификация и есть сущность, смысл передавать UserId и потом опять в handler делать выборку из базы.

Еще вижу многие переносят проверку прав доступа в handler, оставляя в контроллерах только аутентификацию. Но блин, делать конструкцию типа isConsole() вообще не элегантно для пропуска проверка прав доступа при вызове из консольного приложения)) Нет ли более красивого решения?
 

Adelf

Administrator
Команда форума
@alexion Http и консоль не должны ничего знать о сущностях. Их работа простая - передать куда надо, получить что нужно и юзеру показать. То, что некоторые фреймворки позволяют достать объект юзера автоматом вводит разработчиков в соблазн заняться тем, что ты предлагаешь. Надо устоять.

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

Вурдалак

Продвинутый новичок
А почему никто не передает сущность, вместо VO? В чем могут быть подводные камни сделать так?
Проблемы тут как минимум две: если ты правда считаешь, что у тебя уже есть сущность, то зачем вообще нужна команда? Тут же и мог бы дернуть метод сущности. Вторая проблема в том, что User, что фигурирует в районе авторизации — это не тот контекст. То, что написано в User для авторизации, другим контекстам обычно неинтересно.

смысл передавать UserId и потом опять в handler делать выборку из базы
Так в том-то и дело, что скорее всего никакой выборки там нет.

Что касается проверки прав доступа, то мне кажется выносить это в command handler'ы или куда-то там на уровне команды не очень удобно. Хотя бы по той самой причине, по которой ты указал: если дергать из консоли, то там никаких проверок обычно не нужно. Сам по себе доступ к консоли уже обычно подразумевает какие-то админские права. Проще держать command handler'ы независимыми от «внешнего» контекста.
 

Adelf

Administrator
Команда форума
Что касается проверки прав доступа, то мне кажется выносить это в command handler'ы или куда-то там на уровне команды не очень удобно. Хотя бы по той самой причине, по которой ты указал: если дергать из консоли, то там никаких проверок обычно не нужно. Сам по себе доступ к консоли уже обычно подразумевает какие-то админские права. Проще держать command handler'ы независимыми от «внешнего» контекста.
В принципе, да. Но в таком случае нам придётся что-то придумывать для проверки сложных авторизаций, типа «можно редактировать только свою статью». Кто-то предлагал делать ещё один bounded context только для проверки авторизации, кто-то ещё как-то изворачивался. Решение понятное, типа по канонам, но довольно трудоемкое для обычных некрупных проектов.
 
Сверху