Каковы недостатки использования Event Sourcing и CQRS?

Ответ 1

Вот мой пример.

• CQRS + ES может сделать вещи намного проще в сложных программных системах благодаря наличию богатых объектов домена, простых моделей данных, отслеживанию истории, большей видимости проблем, масштабируемости и т.д. concurrency. Это требует иного подхода к системам, поэтому трудно найти квалифицированных разработчиков. Но CQRS упрощает разделение обязанностей между разработчиками. Например, младший разработчик может работать исключительно со стороны чтения без необходимости касаться бизнес-логики.

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

• Я не считаю проблему с более высокой памятью проблемой. Гидратация бизнес-объектов должна производиться по требованию. Объекты не должны содержать ссылки на события, которые уже были сохранены. И гидратация событий должна произойти только при сохранении данных. На стороне чтения у вас нет конверсий Entity → DTO → ViewModel, которые обычно выполняются в многоуровневых системах, и вы не должны отслеживать изменения объектов, которые обычно выполняются полнофункциональными ORM. Большинство систем выполняют значительно больше чтений, чем записи.

• Более длительное время загрузки может быть небольшой проблемой, если вы используете несколько гетерогенных баз данных из-за инициализации различных контекстов данных. Однако, если вы используете что-то простое, например ADO.NET, чтобы взаимодействовать с хранилищем событий и микро-ORM для чтения, система будет "холодным пуском" быстрее, чем любая полнофункциональная ORM. Здесь важна не слишком усложнять доступ к данным. На самом деле проблема CQRS должна решить. И, как я уже сказал, сторона чтения должна быть смоделирована для представлений и не иметь каких-либо накладных расходов на повторное сопоставление данных.

• Двухфазная фиксация может хорошо работать для систем, которые не нужно масштабировать для тысяч пользователей в моем опыте. Вам нужно будет выбрать базы данных, которые будут хорошо работать с координатором распределенных транзакций. PostgreSQL может хорошо работать для чтения и записи отдельных моделей, например. Если система должна масштабироваться для большого количества одновременных пользователей, ее нужно будет спроектировать с возможной последовательностью. Бывают случаи, когда у вас будут сводные корни или границы контекста, которые не используют CQRS, чтобы избежать возможной последовательности. Это имеет смысл для несовместимых частей домена.

• Вы можете запрашивать события в сериализованном формате, таком как JSON или XML, если вы выберете правильную базу данных для хранилища событий. И это должно быть сделано только для целей аналитики. Ничто внутри системы не должно запрашивать хранилище событий ничем иным, как идентификатором совокупного корня и типом события. Эти данные будут индексироваться и жить вне сериализованного события.

Ответ 2

Просто чтобы прокомментировать точку 5. Мне сказали, что Facebook использует ES с Eventual Consistency, поэтому вы можете иногда видеть, как сообщение исчезает и появляется после того, как вы его разместили.

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

Однако через 15 минут ваш SPA переключится на первую, более близкую, читающую модель. Если событие, содержащее ваше сообщение, еще не распространилось на эту модель чтения, вы увидите, что ваш собственный пост исчезнет только для повторного появления позже.

Ответ 3

Я знаю, что прошло почти 3 года с тех пор, как этот вопрос был задан, но, тем не менее, эта статья может быть полезна для кого-то. Ключевые моменты

• Масштабирование со снимками
• Видимость данных
• Изменение схемы
• Работа со сложными доменами
• Нужно объяснить это большинству новых членов команды

Ответ 4

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

Это большое заблуждение. Реляционные базы данных были придуманы именно для эволюции модели (благодаря простым двумерным таблицам в отличие от предварительно определенных иерархических структур). С представлениями и процедурами, обеспечивающими инкапсуляцию доступа к данным, логическая и физическая модель могут развиваться независимо. Именно поэтому SQL определяет DDL и DML на одном языке. Некоторые СУБД также позволяют создавать версии и развертывать все эти разработки в режиме онлайн (непрерывная доставка) в качестве переопределения на основе Oracle Edition.

Большие структуры данных предопределены и могут быть прочитаны только с кодом, разработанным для этой структуры. Хорошо, когда употребляется немедленно, но через 10 лет вам будет трудно прочитать его без точной версии, без языкового компилятора или интерпретатора.

Ответ 5

Надеюсь не опоздать на попытку дать ответ. За эти месяцы я провел много исследований по этому аргументу с целью реализации решения prduction-grade для некоторых частей моей архитектуры, где ES может иметь смысл

Сложный: На самом деле, он не должен быть сложным, его миссия - быть смертельно простой. Как? продвигая всю сложность от кода бизнес-логики до кода инфраструктуры. Доступ к данным должен осуществляться структурами, которые еще недостаточно развиты. Тем не менее, в гонке ES/CQRS нет явного победителя, возможно, потому, что по-прежнему используется нишевый/хипстерский подход (?). Поэтому некоторые команды внедряют свое собственное решение или внедряют некоторые готовые технологии, такие как Axon.

Высокое использование дискового пространства: я бы сказал больше, я бы сказал * потенциально бесконечный * Использование диска. Но если вы идете в сторону ES, у вас также есть очень веская причина, чтобы терпеть этот очевидный мусор. Давайте приведем некоторые из них:

1. Журналы аудита: хранилище данных - это журнал событий, мы его уже знаем. Финансовым приложениям или каждой критически важной миссии/безопасности может потребоваться централизованный журнал аудита, который позволяет указать, кто что сделал в какой момент. ES предоставляет эту возможность коробки... вы также можете украсить свои записи о событиях некоторыми бизнес-метаданными (например, идентификатор транзакции, связанный с некоторой идентификацией потребителя API, уровень серьезности операции...)

2. Высокий параллелизм: существуют системы, в которых логические состояния ресурсов изменяются многими клиентами одновременно. Это игры, платформы IoT и так далее. Ведение журнала событий вместо изменения представления состояния может быть разумным способом предоставления общего порядка событий. Другой способ состоит в том, чтобы делегировать в БД материал синхронизации. Но это не то, что вы хотите, если вы в ES

3. Аналитика Допустим, у вас есть много данных с большой коммерческой ценностью, но вы все еще не знаете, какие именно. В течение многих лет мы извлекали знания из информации приложений, переводя организацию данных с различными информационными моделями (кубами OLAP). Магазин событий снова предоставляет нечто подобное из коробки. Журнал событий - это самая грубая форма представления информации. И у вас может быть много способов обрабатывать их в пакетном режиме или реагируя на сохраненные события.

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

Более длительное время загрузки: если сторона чтения кэширует свои проекции и "запоминает" последнее событие обновления, она не должна повторно применять всю последовательность событий. Снимки - это смягчение, но если вы делаете много снимков, возможно, вы сделали неправильный выбор с ES. Я думаю, что эта проблема является незначительной в экосистемах микросервисов, где время загрузки может быть замаскировано без прерывания обслуживания. Фактически, вы получаете максимальную отдачу от ES/CQRS, когда применяете ее, так что микросервисы

Окончательная согласованность: в этом виновата теорема CAP, а не ES. Многие не ES/CQRS должны иметь дело с этим, но есть много сценариев, где это не является реальной проблемой. Это scnearios, где ES хорошо вписывается. И вы можете смешивать ES и не ES-сервисы на одной платформе

Сериализованные события в хранилище событий: если важно иметь несериализованное представление событий, вы можете использовать БД, ориентированную на документы, но если вы делаете это для запросов к полезной нагрузке событий, вам не хватает точки ES/CQRS. ES означает перенос всех манипуляций с данными со стороны БД на уровень приложений, где каждый элемент быстро меняется, и все не зависит от статистики. Это повышает масштабируемость и отказоустойчивость и предоставляет средства для формирования организации вашей команды, делая такие вещи, как позволить внешнему парню/девушке легко написать свой BFF в javascript.

Я надеюсь применить на практике эти принципы с хорошим результатом и использовать преимущества этого захватывающего подхода