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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

Ответ 4

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

" event sourcing является полностью ортогональным понятием CQRS" (источник) - технически, если вы не используйте ES, вы ничего не теряете из функций CQRS.

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

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

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

Ответ 5

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

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

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

Ответ 6

CQRS существует из-за Event Sourcing, вот что сказал его отец. Если вы можете позволить себе Event Sourcing, вы должны это сделать. Я применил простой подход на основе SQL Server, основанный на Microsoft CQRS Journey.