Применение упрощенных шаблонов CQRS и DDD в микрослужбе

CQRS — это архитектурный шаблон, разделяющий модели для чтения и записи данных. Связанный термин "Разделение запросов команд" (CQS) был первоначально определен Берраном Мейером в своей книге Object-Oriented Software Construction. Основная идея заключается в том, что можно разделить операции системы на две четко разделенные категории:

• Запросов. Эти запросы возвращают результат и не изменяют состояние системы, и они свободны от побочных эффектов.

• Команды. Эти команды изменяют состояние системы.

CQS представляет собой простую концепцию: речь идет о методах в одном объекте, являясь запросами или командами. Каждый метод возвращает состояние или мутирует состояние, но не оба. Даже один объект шаблона репозитория может соответствовать CQS. CQS можно рассматривать как базовый принцип для CQRS.

Разделение ответственности команд и запросов (CQRS) было введено Грегом Янгом и решительно поддерживалась Уди Даханом и другими. Он основан на принципе CQS, хотя это более подробно. Его можно рассматривать как шаблон на основе команд и событий, а также опционально на асинхронных сообщениях. Во многих случаях CQRS связана с более сложными сценариями, например наличие другой физической базы данных для операций чтения (запросов), чем для операций записи (обновлений). Кроме того, более развивающаяся система CQRS может реализовать Event-Sourcing (ES) для базы данных обновлений, поэтому вы будете хранить только события в модели домена вместо хранения данных текущего состояния. Однако этот подход не используется в этом руководстве. В этом руководстве используется самый простой подход CQRS, который состоит из простого разделения запросов от команд.

Аспект разделения CQRS достигается путем группировки операций запросов в одном слое и командах в другом слое. Каждый слой имеет собственную модель данных (обратите внимание, что мы говорим, что модель, не обязательно другая база данных) и строится с помощью собственной комбинации шаблонов и технологий. Более важно, что два уровня могут находиться на одном уровне или микрослужбе, как в примере (микрослужба заказа), используемом для этого руководства. Или они могут быть реализованы в различных микрослужбах или процессах, чтобы их можно было оптимизировать и масштабировать отдельно, не влияя друг на друга.

CQRS означает наличие двух объектов для операции чтения и записи, где в других контекстах есть один. Есть причины иметь денормализованную базу данных чтения, о которой можно узнать в более расширенной литературе CQRS. Но мы не используем этот подход здесь, где цель состоит в том, чтобы иметь большую гибкость в запросах, а не ограничивать запросы ограничениями от шаблонов DDD, таких как агрегаты.

Примером такой службы является микрослужба заказа из эталонного приложения eShopOnContainers. Эта служба реализует микрослужбу на основе упрощенного подхода CQRS. Он использует один источник данных или базу данных, но две логические модели и шаблоны DDD для домена транзакций, как показано на рис. 7-2.

Рис. 7-2. Упрощенная микрослужба на основе CQRS и DDD

Логическая микрослужба "Заказов" включает базу данных заказов, которая может быть, но не обязательно должна быть, тем же сервером Docker. Наличие базы данных в одном узле Docker хорошо подходит для разработки, но не для рабочей среды.

Уровень приложения может быть самим веб-API. Важный аспект проектирования заключается в том, что микросервис разделил запросы и ViewModels (модели данных, специально созданные для клиентских приложений), отделив их от команд, модели домена и транзакций, следуя паттерну CQRS. Этот подход позволяет запросам оставаться независимыми от ограничений и требований, поступающих от шаблонов DDD, которые имеют смысл только для транзакций и обновлений, как объясняется в последующих разделах.

Дополнительные ресурсы

• Грег Янг. Управление версиями в исходной системе событий (Бесплатно читать электронную книгу в Интернете)
  https://leanpub.com/esversioning/read