Выполнение команд и запросов без обработчиков в CQRS?

Question

Мы внедряем корпоративную систему, основанную на доменно-управляемом проектировании, Чистой архитектуре и CQRS.

Однако меня почему-то путают концепции и использование обработчиков в CQRS. В каждом примере, который я видел, выполнение команды делегируется соответствующему обработчику команды.

Я хотел бы знать, возможно ли выполнение команд (или запросов) без обработчиков в CQRS? (или у нас не может быть одного без другого?).

Если это так, можем ли мы отправлять команды непосредственно в нижележащие слои чистой архитектуры (например, Use case, Repository, ...) для продолженияих (без вмешательства обработчиков)?

А как насчет запросов? Им нужны обработчики запросов или мы могли бы просто вызвать модель чтения непосредственно в наших REST API?

Answer 1

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

Типичные примеры команд в CQRS содержат Command и Command Handler, но они должны иллюстрировать некоторые важные принципы:

• API-интерфейсы fire Command s и забудьте
• API для Command s не возвращают данные вызываемому абоненту
• Command Handler s выбирают Command из очередей сообщений и обрабатывают их
• Command s приведет к изменениям, которые станут видимыми / доступными в более поздний момент времени, благодаря возможной согласованности

Вам не нужно использовать Command + Command Handler s, если вы толькозадача состоит в том, чтобы отделить запись от слоя чтения. Вы можете вызывать простые методы службы приложений из уровня API. Просто убедитесь, что вы следуете принципам CQRS, например, не разделяете код между сторонами записи и чтения, не возвращаете данные вызываемой стороне при write / изменениях и имеете конвейер событий для построения моделей запросов.

ItБыло бы также полезно выполнить фактическое изменение как часть фонового работника, а не службы приложений, чтобы обеспечить асинхронную рабочую модель.

Сказав, что следование шаблону Command + Command Handlerоднако, это очень помогает вам, облегчая рассуждения об архитектурных решениях во время разработки.

Модели запросов, с другой стороны, обычно создаются для непосредственного обращения к запросам API. Другими словами, один и тот же агрегат или концепция в вашем домене может иметь несколько построенных структур модели запросов для удовлетворения различных требований API. Обычно вы возвращаете уже созданный Query Model (без какой-либо последующей обработки) в ответ на синхронные вызовы API. Да, вы просто вызываете модель чтения непосредственно в своих API-интерфейсах REST или через методы-оболочки в службах приложений.