Поясните за CQRS/Event Sourcing/DDD
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Есть несколько скользких вопросов по архитектуре касательно CQRS/Event Sourcing/DDD, т.к. сам IRL не сталкивался, а из знакомых кто сталкивался, то очень поверхностно, и деталей не знают. В статьях толковых объяснений «на пальцах» с примерами сайд-эффектов особо не нашёл — все слишком специфичны и слабо интегральны («вот мы сделали так-то в таком-то случае», при этом большая картина остаётся в тумане войны).
1. Подразумевает ли это полностью реактивный фронт? Я так понимаю, что да, т.к.:
1.1. Нет смысла сразу же вычитывать проекцию, если мы даже не знаем, успела ли она обновиться после реквеста и соответствующей команды.
1.2. Книжное понимание CQRS (и CQS) подразумевает, что команда ничего и никогда не возвращает, НО при автогенерации айдишечки базой при создании сущности мы даже при желании вычитать созданную сущность не сможем, если у нас не будет айди. Кстати, упомянутый выше Mark Seemann предложил вот это как вариант, и Грег Янг туда же (с аргументами «а если будет батч из команд на один реквест вместо одной, а что с идемпотентностью»), и многие другие люди, но я пока внутренне не могу этого принять)).
2. Баги. В «стандартной» системе бывает так, что обнаруживаются старые пропущенные ошибки, которые привели к неправильным данным в базе. В этом случае мы, что делать, идём и правим базу (может, даже не одну) либо с помощью языка запросов, либо, если всё сложно, пишем отдельную тулу для этого. Но что делать, если мы уже напедалили проекций, одни ивенты породили другие ивенты, которые лежат в ивент сторе, и т.д.? Понятно, что необязательно делать всю систему такой, и не всегда прям будут такие апокалиптические цепочки, но чем больше охват, тем больше риск. Да и в целом любая ошибка (вроде как) сделает больше беды, чем обычно.
3. Бизнес-валидации и возврат ошибок — наверное, самая контраверсионная тема. Люди говорят противоположные вещи (большинство, что проекции нельзя юзать для валидации, но тот же Грег Янг в своих видео достаточно язвительно, как он любит, заявляет в сторону первой группы, что куча кейсов, когда можно). В инете гуляет много вариантов под разные юз-кейсы:
3.1. Если данные для валидации касаются только одной сущности, для каждой сущности используется свой стрим/коллекцию/you name it со своим ID, чтобы проигрывать ивенты из стора каждый раз, и получать реальное состояние. Но если что-то часто меняется, может же быть печаль с перформансом из-за постоянного реплея (даже с учётом снепшотов в ивент сторе)?
3.2. Для узкого кейса «уникальность значения» создаётся отдельное индексное хранилище (напр., таблица) а-ля «если там такое уже есть, то нельзя». Выглядит так себе.
3.3. Если нужно много данных для валидации, и требуется восстанавливать состояния агрегатов, то даунсайд по перформансу из п. 3.1 может(?) здесь выстрелить ещё сильнее (в зависимости от размера агрегатов).
13 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів