Представь обычную ситуацию.

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

В базе у тебя остаётся только финальное состояние. Просто запись “как есть сейчас”. Всё, что происходило до этого, исчезает.

Ты не увидишь, какие товары удаляли, где пользователь сомневался, на каком шаге что-то пошло не так. Для отладки, аналитики и аудита это слепая зона.

Пока у тебя простой CRUD на ASP.NET Core и Entity Framework Core, это может не мешать. Но как только появляются бизнес-процессы посложнее, начинаются проблемы. Нет истории - нет понимания.

Здесь пригодится Event Sourcing.

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

События неизменяемые. Ты их не редактируешь и не удаляешь. Только добавляешь новые.

Каждая сущность превращается в поток событий. У корзины своя последовательность: создали, добавили товар, удалили, оформили заказ.

Текущее состояние собирается из этих событий. В

C# это обычно выглядит как агрегат, который проигрывает события и восстанавливает состояние в памяти. Плюс там же проверяются бизнес-правила перед добавлением новых событий.

Для чтения строятся отдельные модели. Например, через Marten или тот же PostgreSQL. Они обновляются сразу или асинхронно и отдают данные в API.

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

CRUD отвечает на вопрос “что сейчас в базе”.
Event Sourcing отвечает на вопрос “что реально происходило”.

И для сложных систем это уже не архитектурный стиль, а вопрос выживания проекта.

Гайд по эвент-сорсингу