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

Question

Моя команда и я обсуждали использование шаблона проектирования CQRS (Command Query Responsibility Segregation), и мы все еще пытаемся оценить плюсы и минусы его использования.Согласно: http://martinfowler.com/bliki/CQRS.html

мы еще не видели достаточно использования CQRS на местах, чтобы быть уверенными, что понимаем его плюсы и минусы

Так что вы думаете, ребята, когда возникает проблема с использованием CQRS?

Answer 1

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

Это концепция, основанная на доменно-управляемом дизайне (DDD).И важной стратегической концепцией DDD является так называемый ограниченный контекст .

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

• например, часть вашей команды находится в другой стране
• или вам сложно общаться лицом к лицуЭто означает, что вы хотите отделить модели чтения от объектов записи (sagas, domain, CRUD)

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

Answer 4

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

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

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

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

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

Answer 5

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

1. Чрезвычайная способность масштабирования
2. Очень полезно, когда речь идет о распределенных командах.1006 *

Answer 6

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

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

Answer 7

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

1. Масштабируемость (чтение превышает запись, поэтому требования к масштабированию для каждого из них различны и могут быть рассмотрены лучше)
2. Гибкость (отдельные модели чтения / записи)
3. Снижение сложности (перенос сложности на отдельные задачи)
4. Сконцентрируйся на Домене / Бизнесе
5. Облегчает разработку интуитивно понятных пользовательских интерфейсов на основе задач