Недостати при комбинации нескольких команд во время одного запроса/процесса в CQRS подходе?
При изучении CQRS (синхронно, без ES) появилось несколько вопросов, на которые, увы, не нашел прямой информации в интернете. Везде приводят в примеры примитивные приложения, состоящие из 2х-3х команд, типа: создать пользователя, получить его данные, удалить и т.д..
Вопросы:
1. Допустим, в моей системе имеется 2 команды (command) и их обработчики (command handlers): 1 - создает пользователя, 2 - активирует его аккаунт. Но тут приходит бизнес и говорит: "Для пользователей, у которых почтовый адрес от gmail, аккаунты должны активироваться сразу же, в момент создания". Как в этом случае должен выглядеть контроллер, который обрабатывает запрос на создание пользователя? Должен ли он после вызова обработчика создания пользователя, сразу же вызвать обработчик активации аккаунта если почтовый адрес от gmail? Вопрос можно сформулировать так: имеет ли какие-то недостатки, подход, комбинирования обработчиков команд при обработке единого запроса?
2. На сколько правильный подход учитывать, что комманды и их обработчики буду реюзабельны, например при создании api к системе? Тут можно привести пример блога. У нас, в блоге, имеется страница с самой статьей, на которой помимо статьи выводятся доп. элементы, к примеру, "5 похожих статей". В случае веб-сайта, наш обработчик (query handler) помимо информации о статье, так же выберет из хранилища "5 похож статей". В случае API, эндпоинт "/post/1/details" должен отдать только информацию о статье, без "5 похожих статей". Лично я вижу 2 варианта на проектирование комманд (в данном слушает это query) и их обработчиков: 1 - для веб-сайта это PostDetailsQueryHandler и SimilarPostsQueryHandler (опять же вопрос про комбинации команд в первом моем вопросе), тогда api будет использовать только PostDetailsQueryHandler. 2 - для веб-сайта это будет что-то типа WebPostDetailsQueryHandler (который так же вытянет нам "5 похожих статей", а для api это будет ApiPostDetailsQueryHandler.
Нууууу, IT depends как говорится, но:
1. тут все интересно - в CQRS все забывают о том что нужно поддерживать ВЕРСИОНИРОВАНИЕ КОМАНД. Да-да. И код очень редко когда удаляется из системы чтобы поддерживать старые версии
2. перестать заниматься фигней, осознать что это два разных микросервиса. Соответственно эндпоинты у низ разные. Хочешь делать одним запросом - ставь что-нибудь вроде GraphQL поверх
>обработчик активации аккаунта если почтовый адрес от gmail?
не вижу никаких проблем чтоб обработчик, в этом случае, сам создал команду на активацию эккаунта.
>Лично я вижу 2 варианта на проектирование комманд
рабочая схема, но вы начинаете множите сущности там где этого особо и не требуется, заставьте свой сайт использовать тотже самый апи, который будут использовать сторонние сервисы, и сделайте его единым для всех.
Мне кажется неплохо было бы разделить действия "запроса статьи" и "получения рекомендаций к статье".
1. Допустим, в моей системе имеется 2 команды (command) и их обработчики (command handlers): 1 - создает пользователя, 2 - активирует его аккаунт. Но тут приходит бизнес и говорит: "Для пользователей, у которых почтовый адрес от gmail, аккаунты должны активироваться сразу же, в момент создания". Как в этом случае должен выглядеть контроллер, который обрабатывает запрос на создание пользователя? Должен ли он после вызова обработчика создания пользователя, сразу же вызвать обработчик активации аккаунта если почтовый адрес от gmail? Вопрос можно сформулировать так: имеет ли какие-то недостатки, подход, комбинирования обработчиков команд при обработке единого запроса?
После выполнения команды на создание пользователя необходимо опубликовать событие об этом, а дальше некий обработчик в своем коде будет проверять email и если он от gmail, то формирует команду на активацию и дальше в шину её, или куда там у вас...
Сложный
