CQRS без Event Sourcing - каковы недостатки?

Question

Помимо отсутствия некоторых преимуществ Event Sourcing, есть ли другие недостатки в адаптации существующей архитектуры к CQRS без части Event Sourcing?

Я работаю над большим приложением, и разработчики должны иметь возможностьобрабатывать разделение существующей архитектуры на Команды и Запросы в течение следующих нескольких месяцев, но просить их также добавить в Event Sourcing на этом этапе было бы ОГРОМНУЮ проблему с точки зрения ресурсов.Я совершаю крещение, не включая Event Sourcing?

Answer 1

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

Большинство преимуществ, приписываемых ES, можно получить, сохранив ваши события в простом журнале событий. Вам не нужно отбрасывать постоянство на основе состояния (но в долгосрочной перспективе вы, вероятно, это сделаете, потому что в какой-то момент это станет логическим следующим шагом).

Моя рекомендация: ключом является простота. Делайте один шаг за раз, особенно когда вводите такой драматический сдвиг парадигмы. Начните с простого CQRS, затем введите журнал событий, когда вы (и ваша команда) привыкли к новым концепциям. Затем, если потребуется, измените вашу настойчивость на Event Sourcing и запустите DBA; -)

Answer 2

Я полностью согласен с Деннисом, ES не является предварительным условием для CQRS, на самом деле CQRS сам по себе довольно прост в реализации и может реально упростить ваш дизайн.

Вы можете найти плавное введение вэто здесь

Во-вторых, какие преимущества приносит сама CQRS в таблицу?

• Упрощает ваши доменные объекты, высасывая все вопросы запроса
• Делает возможным масштабирование кода, ваши запросы разделены и могут быть легко настроены
• Когда вы перебираете дизайн своего продукта, вы можете добавлять / удалять / изменять отдельные команды / запросы, вместо того, чтобы работать с более крупными структурами, какцелое (например, сущности, агрегаты, модули).
• Команды и запросы создают хорошо известный словарь для общения с экспертами в предметной области.Другие архитектурные паттерны (например, каналы и фильтры, актеры) используют термины и концепции, которые непросто понять непрограммистам.
• Ограничивает использование ORM (если вы его используете), я считаю, что ORM вводит неоправданносложность, если вы попытаетесь использовать их для запросов, абстракции утечек и тяжелы, попытка настроить их - ночная кобыла :) Использование ORM только на командной стороне делает вещи намного проще, простой старый SQL лучше всего подходит для запросов, вероятно,использование простой библиотеки для преобразования наборов результатов в DTO - это самое необходимое.

Подробнее о том, как можно найти преимущества CQRS, здесь

Также незабудьте о нематериальных преимуществах CQRS

Если у вас все еще есть сомнения, вы можете прочитать это

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

Не стесняйтесь отправить мне сообщение в личкуЕсли вы хотите узнать что-то более конкретное.

Answer 3

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

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

Когда ваше приложение станет более сложным, вам будет очень больно в заднице делать его задом наперед.совместимый.

Answer 4

Я думаю, что Event Sourcing заставляет людей бояться CQRS. И это по причине. Это не естественно - когда вы взаимодействуете с чем-то в реальном мире, вам не нужно получать полную историю об этом объекте.

« источник событий является полностью ортогональной концепцией для CQRS » ( source ) - технически, если вы не используете ES, вы ничего не теряете из функций CQRS.

Я понятия не имею, почему Event Sourcing рассматривается как единственная основа для решения некоторых проблем, связанных с «обменом сообщениями», таких как: дублирование / отсутствие сообщений, изменение порядка сообщений и коллизии данных и т. Д. Это неправда, если вы не t Используя Event Sourcing, вы не можете создавать инкапсулированные средства для решения таких проблем другим способом.

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

Я предлагаю подход «подписанные документы», при котором ваши данные рассматриваются не как состав событий модификации, а как состав неизменных частей, подписанных ответственными пользователями. Я уверен, что может быть много других решений для реализации потока сообщений и хранения данных. И вам нужно учитывать свою бизнес-модель при выборе того, который вам нравится использовать.

Answer 5

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

Прежде всего, у вас почти наверняка возникнут проблемы с синхронизацией вашей модели запросов с моделью Command.В хранилище событий, если сторона запроса когда-либо не синхронизируется, вам просто нужно воспроизвести события, чтобы исправить это.В любом случае, это теория!

Но с помощью Event Sourcing вы также можете хранить полную историю всех транзакций сущностей.А это значит, что вы можете решить создавать новые запросы и представления после реализации.Это очень часто представления, которые не были бы возможны с CQRS не из источников.Я слышал, как Грег Янг приводит пример запроса товаров, которые были добавлены, а затем удалены из корзины покупок.С Event Sourcing это возможно.Без ES это невозможно, потому что вы сохраняете только конечное состояние корзины.