Когда использовать шаблон проектирования CQRS?

Ответ 1

CQRS не является шаблоном, охватывающим все приложение.

Это концепция, основанная на Domain Driven Design (DDD). Важной стратегической концепцией DDD является так называемый Ограниченный контекст.

В типичном приложении есть несколько ограниченных контекстов, любой из которых может быть реализован так, как это имеет смысл. Например,

• Управление пользователями → CRUD
• Выставление счетов → CRUD
• Управление страховыми полисами (основной домен) → CQRS
• ...

Это, вероятно, не отвечает на ваш вопрос, но может дать немного больше информации о теме. Честно говоря, я не думаю, что на него можно ответить вообще, не учитывая специфику проекта, и даже тогда редко бывает что-то вроде определенной лучшей практики.

Ответ 2

Ну критики CQRL могут сказать, что CQRS сложна, и это может быть правдой.

Конечно, это добавляет накладные расходы, создавая простое приложение CRUD в стиле CQRS, поэтому я бы рассмотрел использование CQRS только в следующих случаях:

• Большая команда. Вы можете легко разделить задачи разработки между людьми, если выбрали архитектуру CQRS. Ваши лучшие люди могут работать над логикой домена, оставляя обычные вещи менее опытным разработчикам.
• Сложная бизнес-логика - CQRS заставляет вас избегать смешения логики домена и инфраструктурных операций.
• Масштабируемость. С CQRS вы можете добиться отличной производительности для чтения и записи, обработку команд можно масштабировать на нескольких узлах, а запросы - это операции только для чтения, которые можно оптимизировать для выполнения быстрых операций чтения.

Ответ 3

Если у вас сложный или жесткий бизнес-домен и:

• с источником событий; вы хотите хороший способ тестирования логики
• с источником событий; вы хотите доказать свое поведение посредством тестирования и рассуждений.
• у вас несколько клиентов или потребителей вашей службы домена (а не только одного веб-сервера).

ИЛИ у вас есть пользователи, которым необходимо действовать по общим данным:

• и вы хотите формализовать концепции слияния данных своего домена.
• или вы хотите применить логику для слияния событий

ИЛИ у вас есть требования к масштабируемости:

• вы применяете шаблон как шаблон денормализации, который устраняет узкие места
• вы хотите масштабировать горизонтально, а не вертикально

ИЛИ у вас проблемы с производительностью (другая сторона масштабируемости):

• например. вам нужно перенести свою архитектуру в архитектуру, управляемую событиями - CQRS как шаблон является хорошим шагом.

ИЛИ у вас есть команда, которая физически отключена:

• например. части вашей команды находятся в другой стране.
• или трудно получить личную связь, поэтому вы хотите отделить читаемые модели от записи вещей (саги, домен, CRUD).

Это не CQRS, который слишком сложный, это компьютеры, которые есть.

Ответ 4

Когда использовать шаблон проектирования CQRS?

Структура архитектуры CQRS может использоваться, когда трудно получить запрос от репозиториев на все данные, которые пользователи должны просматривать. Это особенно актуально, когда дизайн UX создает представления данных, которые пересекают несколько типов и экземпляров агрегатов. Чем сложнее ваш домен, тем больше это имеет значение.

Если это не подходит для компрометации дизайна UX, использование CQRS пытается смягчить проблемы, связанные с другими решениями, например:

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

Подводя итог: используйте CQRS, когда его трудно запросить из репозиториев данные, которые пользователи должны просматривать, которые, как правило, происходят, тем сложнее ваш домен.

Ответ 5

С моей точки зрения это добавляет два основных преимущества. (Среди многих других)

• Экстремальная масштабируемость
• Очень полезно, когда дело доходит до распределенных команд.

Ответ 6

Ниже приводятся причины использования CQRS:

• Масштабируемость (чтение превышает запись, так что требования к масштабированию для каждого отличаются и могут быть исправлены лучше).
• Гибкость (отдельные модели чтения/записи)
• Уменьшенная сложность (смещение сложности в отдельные проблемы)
• Концентрация на домене/бизнесе
• Облегчает разработку интуитивно понятных пользовательских интерфейсов на основе задач

Ответ 7

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

В таком случае вы можете рассмотреть возможность создания отдельной модели чтения, которая будет быстрее развиваться и может иметь более быстрое время выполнения.