Перенос реляционных данных в хранилище событий

Question

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

Текущее состояние в этом процессе: у меня есть команды, которые вносят изменения, и объекты запросов, которые изолируют запросы.Это означает, что от клиента к серверу у меня есть CQRS-способ изменения и запроса данных, хотя я не публикую никаких событий из-за изменений и не имею денормализованного хранилища для чтения.Я должен упомянуть, что у меня также есть довольно анемичные DTO как моя «модель предметной области».Все поведение было распределено по n-уровневым слоям с его обработчиками, менеджерами и всеми этими ужасными слоями.

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

Как я могу перенести данные из хранилища данных отношений в хранилище событий?

У меня очень нормализованная модель данных с очень важными данными, которые необходимо перенести.Я понимаю, что не могу рассчитывать на захват каких-либо намерений из этих данных, поскольку они мертвы, но что мне с этим делать?Должен ли я создавать множество команд миграции?Было бы приятно услышать ваш опыт от этого.

Answer 1

У меня не было возможности попробовать это, но кое-что, что я хотел попробовать, работало бы в несколько этапов:

1. Сначала наметьте все события, которые понадобятся системе.
2. Затем введите представления в реляционную базу данных для представления событий.
3. Напишите пользовательскую утилиту для выбора из представлений для построения правильных объектов событий.
4. Попросите пользовательскую утилиту записатьобъекты событий в хранилище событий в правильной последовательности.
5. Наконец, убедитесь, что обновили денормализованные модели представлений из хранилища событий.

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

Я решил, что создание объектов событий более целесообразно, чем создание команд, поскольку реляционные данные представляют домен для действий, которые произошли в прошлом.

Answer 2

Id по-другому подходит к предлагаемым решениям.Я дважды выполнил эту миграцию для двух разных проектов.

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

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

Это просто означает, что в обработчике команд просто создайте события и поместите их в EventStore.

Чем раньше в жизни проектов вы начинаете фиксировать события, тем большеистория, которая у вас есть в вашем приложении.

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

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

Все, что вы сделали сейчас, это переместили ответственность WRITE в денормализатор и удалили из обработчика команд.

Это в основном процесс, который я бы порекомендовал, как я уже говорил, я сделал это дважды, и он работает.

Вопрос переноса СУЩЕСТВУЮЩИХ данных в вашей базе данных на события немного сложен.Вы должны думать об этих данных как о текущем состоянии, поэтому все, что вы можете сделать, - это создать и зафиксировать (используя какую-то написанную вами утилиту). Создать события для всех данных в ваших системах.

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

Answer 3

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