Применение подходов CQRS и CQS в микрослужбе DDDd в eShopOnContainers

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

Проектирование микрослужбы заказа в справочном приложении eShopOnContainers основано на принципах CQRS. Однако он использует самый простой подход, который просто отделяет запросы от команд и использует одну и ту же базу данных для обоих действий.

Суть этих моделей заключается в том, что запросы являются идемпотентными: сколько бы раз вы ни обращались к системе, состояние этой системы не изменится. Другими словами, запросы свободны от побочных эффектов.

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

С другой стороны, команды, которые активируют транзакции и обновления данных, изменяют состояние в системе. С помощью команд необходимо быть осторожным при работе с сложностью и постоянно изменяющимися бизнес-правилами. Здесь вы хотите применить методы DDD для более эффективной моделироваемой системы.

Шаблоны DDD, представленные в этом руководстве, не должны применяться универсально. Они вводят ограничения на дизайн. Эти ограничения обеспечивают такие преимущества, как более высокое качество с течением времени, особенно в командах и другом коде, который изменяет состояние системы. Однако эти ограничения добавляют сложность с меньшими преимуществами для чтения и запроса данных.

Один из таких шаблонов — это шаблон агрегата, который мы рассмотрим в более поздних разделах. Кратко говоря, в шаблоне агрегата многие объекты домена рассматриваются как единая единица в результате их отношений в домене. Вы не всегда можете получить преимущества из этого шаблона в запросах; это может повысить сложность логики запроса. Для запросов, доступных только для чтения, вы не получаете преимущества обработки нескольких объектов как единого агрегата. Вы получаете только сложность.

Как показано на рисунке 7-2 в предыдущем разделе, в этом руководстве рекомендуется использовать шаблоны DDD только в области транзакций или обновлений микрослужбы (т. е. по мере активации команд). Запросы могут следовать более простому подходу и должны быть отделены от команд, следуя подходу CQRS.

Для реализации "стороны запросов" можно выбрать один из множества подходов, таких как полноценный ORM, например EF Core, проекции с помощью AutoMapper, хранимые процедуры, представления, материализованные представления или микро ORM.

В этом руководстве и в eShopOnContainers (в частности, микрослужба заказа) мы решили реализовать прямые запросы с помощью микро ORM, например Dapper. Это руководство позволяет реализовать любой запрос на основе инструкций SQL, чтобы получить лучшую производительность благодаря легкой платформе с небольшими затратами.

При использовании этого подхода любые обновления модели, влияющие на то, как сущности сохраняются в базе данных SQL, также требуют отдельных обновлений запросов SQL, используемых Dapper или другими отдельными (не EF) подходами к запросу.

Шаблоны CQRS и DDD не являются архитектурами верхнего уровня

Важно понимать, что CQRS и большинство шаблонов DDD (например, слои DDD или модель домена с агрегатами) не являются архитектурными стилями, а только шаблонами архитектуры. Микрослужбы, SOA и архитектура на основе событий (EDA) являются примерами архитектурных стилей. Они описывают систему многих компонентов, таких как многие микрослужбы. Шаблоны CQRS и DDD описывают что-то внутри одной системы или компонента; В этом случае что-то внутри микрослужбы.

Разные ограниченные контексты (BCs) будут использовать разные паттерны. Они имеют разные обязанности, и это приводит к различным решениям. Стоит подчеркнуть, что принудительное применение одного и того же шаблона везде приводит к сбою. Не используйте шаблоны CQRS и DDD везде. Многие подсистемы, контроллеры домена или микрослужбы проще и могут быть реализованы проще с помощью простых служб CRUD или с помощью другого подхода.

Существует только одна архитектура приложения: архитектура системного или комплексного приложения, которое вы разрабатываете (например, архитектура микрослужб). Однако дизайн каждого ограниченного контекста или микрослужбы в этом приложении отражает свои собственные компромиссы и внутренние решения по проектированию на уровне шаблонов архитектуры. Не пытайтесь применять те же архитектурные шаблоны, что и CQRS или DDD повсюду.

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

НазадДалее

  • Last updated on