CQRS без Event Sourcing - каковы недостатки?
Помимо упущения некоторых преимуществ Event Sourcing, есть ли другие недостатки в адаптации существующей архитектуры к CQRS без компонента Event Sourcing?
Я работаю над большими приложениями, и разработчики должны быть в состоянии справиться с разделением существующей архитектуры на Команды и Запросы в течение следующих нескольких месяцев, но попросить их также добавить в Event Sourcing на этом этапе будет ОГРОМНУЮ проблему из-за ресурсов перспектива. Я совершаю кощунство, не включая Event Sourcing?
5 ответов
Event Sourcing является необязательным и в большинстве случаев усложняет ситуацию больше, чем помогает, если вводится слишком рано. Особенно при переходе от устаревшей архитектуры и даже больше, когда команда не имеет опыта работы с CQRS.
Большинство преимуществ, приписываемых ES, можно получить, сохранив ваши события в простом журнале событий. Вам не нужно отбрасывать постоянство на основе состояния (но в долгосрочной перспективе вы, вероятно, это сделаете, потому что в какой-то момент это станет логическим следующим шагом).
Моя рекомендация: простота - это ключ. Делайте один шаг за раз, особенно когда вводите такой драматический сдвиг парадигмы. Начните с простого CQRS, затем введите Журнал событий, когда вы (и ваша команда) привыкли к новым концепциям. Затем, если потребуется, измените свое постоянство на Event Sourcing и запустите DBA;-)
Я полностью согласен с Деннисом: ES не является предварительным условием для CQRS, на самом деле CQRS сам по себе довольно прост в реализации и может реально упростить ваш дизайн.
Вы можете найти плавное введение в это здесь
Во-вторых, какие преимущества приносит сама CQRS?
- Упрощает ваши доменные объекты, высасывая все вопросы запроса
- Делает возможным масштабирование кода, ваши запросы разделены и могут быть легко настроены
- Поскольку вы перебираете дизайн своего продукта, вы можете добавлять / удалять / изменять отдельные команды / запросы, вместо того, чтобы иметь дело с более крупными структурами в целом (например, сущностями, агрегатами, модулями).
- Команды и запросы создают хорошо известный словарь для общения с экспертами в предметной области. Другие архитектурные шаблоны (например, каналы и фильтры, действующие лица) используют термины и понятия, которые непросто понять непрограммистам.
- Ограничивает использование ORM (если вы его используете), я чувствую, что ORM вносит неоправданную сложность, если вы пытаетесь использовать их для запросов, абстракции неплотны и тяжелы, пытаться настроить их - ночная кобыла:) Использование ORM только на командная сторона делает все намного проще, простой старый SQL лучше всего подходит для запросов, вероятно, вам больше всего нужно использовать простую библиотеку для преобразования наборов результатов в DTO.
Подробнее о том, как преимущества CQRS могут быть найдены здесь
Также не стоит забывать о не ощутимых преимуществах CQRS
Если у вас все еще есть сомнения, вы можете прочитать это
В настоящее время мы используем CQRS для проектов средней сложности и обнаружили, что он очень подходит. Мы начали с использования пользовательского кода начальной загрузки и теперь перешли к использованию Axon Framework, чтобы предоставить нам некоторые компоненты инфраструктуры
Не стесняйтесь PM мне, если вы хотите узнать что-то более конкретное.
Существует фундаментальная проблема шаблона поиска событий, заключающаяся в том, что события в хранилище событий могут быть несовместимы с вашими обработчиками событий в приложении из-за изменения кода.
При этом всякий раз, когда вы изменяете обработчик событий, добавляя новые функции, вам нужно думать о обратной совместимости. Вы должны убедиться, что ваш код всегда может обрабатывать одно и то же событие на разных этапах, созданных другой версией вашего кода.
Когда ваше приложение станет более сложным, вам будет очень больно делать его обратно совместимым.
Я думаю, что Event Sourcing - это то, что заставляет людей бояться CQRS. И это по причине. Это не естественно - когда вы взаимодействуете с чем-то в реальном мире, вам не нужно получать полную историю об этом объекте.
" Источник событий - это полностью ортогональная концепция для CQRS " ( источник) - технически, если вы не используете ES, вы ничего не теряете от функций CQRS.
Я понятия не имею, почему Event Sourcing рассматривается как единственная основа для решения некоторых проблем, связанных с "обменом сообщениями", таких как: дублирование / отсутствие сообщений, изменение порядка сообщений и коллизии данных и т. Д. Это неправда, если вы не используете Event С помощью источников вы не можете создать инкапсулированные средства для решения таких проблем другим способом.
Как я вижу альтернативные способы реализации обмена сообщениями в CQRS с использованием другого принципа организации данных, вы можете прочитать здесь.
Я предлагаю подход "подписанные документы", при котором ваши данные рассматриваются не как состав событий модификации, а как состав неизменных частей, подписанных ответственными пользователями. Я уверен, что может быть много других решений для реализации потока сообщений и хранения данных. И вам нужно учитывать свою бизнес-модель при выборе того, который вам нравится использовать.
На мой взгляд, лучшая структура на основе шаблонов CQRS - это MediatR от Джимми Богарда. Если вам не нужен Event Sourcing в начале разработки приложения, MediatR - правильный выбор. Вот репозиторий - https://github.com/jbogard/MediatR
На мой взгляд, вы делаете большую ошибку, не используя источник событий с CQRS.
Во-первых, у вас почти наверняка возникнут проблемы с синхронизацией модели Query с моделью Command. В хранилище событий, если сторона запроса когда-либо не синхронизируется, вам просто нужно воспроизвести события, чтобы исправить это. Это теория в любом случае!
Но с помощью Event Sourcing вы также можете хранить полную историю всех транзакций сущностей. А это значит, что вы можете решить создавать новые запросы и представления после реализации. Это очень часто представления, которые не были бы возможны с CQRS не из источников. Я слышал, как Грег Янг приводит пример запроса товаров, которые были добавлены, а затем удалены из корзины покупок. С Event Sourcing это возможно. Без ES это невозможно, потому что вы сохраняете только конечное состояние корзины.
CQRS существует благодаря Event Sourcing, так сказал его отец. Если вы можете позволить себе Event Sourcing, вы должны это сделать. Я реализовал простой подход на основе SQL Server, основанный на Microsoft CQRS Journey.