Миграция устаревшей базы данных в представление cqrs / event sourcing

Question

Мы получили старое унаследованное приложение со сложной бизнес-логикой c, которое нам нужно переписать. Мы рассматриваем использование cqrs и источников событий. Но не ясно, как перенести данные из старой базы данных. Возможно, нам нужно перенести его только в базу данных для чтения, поскольку мы не можем воспроизвести все события, чтобы заполнить хранилище событий. Но нам нужно хотя бы создать несколько начальных записей в хранилище событий для каждого агрегата, например AggregateCreated? Или нам нужно написать сценарии и использовать все команды по одной для воссоздания агрегатов таким же образом, как мы это обычно делаем с источником событий?

Answer 1

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

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

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

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

Answer 2

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

Нет, ваша база данных модели чтения может быть отброшена и воссоздана в любое время на основе стороны записи, только источником для записи является ваш источник правда.

Но, по крайней мере, нам нужно создать несколько исходных записей в хранилище событий для каждого агрегата, например, AggregateCreated?

Конечно, и ТОЛЬКО начальное событие может быть недостаточно , Если ваш текущий OrderAggregate имеет резервирования, вы должны создать ItemReservedEvent для каждого резервирования, которое у него есть.

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

Такое чувство, что вы должны go. Считайте старый агрегат / сущность из БД и попробуйте сопоставить его с новым.