Перейти к содержанию

Недостатки порождения событий

Другая модель программирования с высоким порогом вхождения

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

Сложность приложения, основанного на обмене сообщениями

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

Меняющиеся события могут создать проблемы

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

Усложняется удаление данных

Одной из целей порождения событий является сохранение истории агрегатов, поэтому данные намеренно хранятся вечно. При использовании этого шаблона используется мягкое удаление — генерация события Deleted и установка флага удалён.
Проблема возникает, когда удаление данных является требованием законодательства, например GDPR. Согласно ему приложение должно забыть личную информацию пользователя, такую как адрес электронной почты. А этот адрес может храниться в событии, например, AccountCreated или использоваться в качестве первичного ключа для агрегата.
Один из механизмов решения этой проблемы — шифрование. Каждый пользователь имеет ключ шифрования, хранящийся в отдельной таблице БД, и вся персональная информация шифруется этим ключом. Когда пользователь запрашивает удаление всех своих данных, приложение удаляет из БД запись с ключом, тем самым уничтожая данные пользователя (так как их больше нельзя расшифровать).

Трудности при обращении к хранилищу событий

Представим, что нужно найти клиентов, исчерпавший свой кредитный лимит. Так как у нас нет столбца с кредитыми средствами, мы не можем написать запрос типа SELECT * FROM CUSTOMER WHERE CREDIT_LIMIT = 0, вместо этого нужно использовать сложные запросы, вычисляющие кредитный лимит свёрткой событий. С хранилищами NoSQL еще больше проблем. Следовательно, необходимо реализовывать запросы при помощи методики CQRS.


Последнее обновление : 25 мая 2023 г.
Дата создания : 29 июля 2022 г.

Комментарии

Комментарии