Command bus и CQRS

  • Автор темы Автор темы Adelf
  • Дата начала Дата начала
Выглядит как попытка сэкономить на написании пары символов.
Я, конечно, предпочел бы вариант с передачей value objects - хотя бы потому, что они могут понадобиться и в другой команде (один HTTP-запрос запросто может приводить к выполнению нескольких команд, почему бы и нет).
Но, в принципе, в данном конкретном случае никакого особого вреда, кроме неявности выбрасываемого исключения, не вижу.
 
А почему никто не передает сущность, вместо 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() вообще не элегантно для пропуска проверка прав доступа при вызове из консольного приложения)) Нет ли более красивого решения?
 
@alexion Http и консоль не должны ничего знать о сущностях. Их работа простая - передать куда надо, получить что нужно и юзеру показать. То, что некоторые фреймворки позволяют достать объект юзера автоматом вводит разработчиков в соблазн заняться тем, что ты предлагаешь. Надо устоять.

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

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

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