Как начать использовать CQRS с Axon framework в существующей базе данных

У нас есть существующее веб-приложение, использующее базу данных графов, которую мы хотим переключить на архитектуру, использующую cqrs с фреймворком Axon.

Мне интересно, есть ли какие-нибудь передовые методы, что делать с данными, которые уже находятся в нашей производственной базе данных. Нам нужно заполнить базу данных индекса (elasticsearch), которую я хотел бы постоянно обновлять с помощью прослушивателей событий. Этот индекс необходимо инициализировать данными, которые уже находятся в производстве, но не имеют связанных с ними событий.

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

Звучит как хорошая идея? Есть еще мысли по этому поводу?


cqrs axon
person Wouter    schedule 11.06.2014    source источник
comment
попробуйте спросить в сообществе axon groups.google.com/forum / #! forum / axonframework < / а>   -  person bilak    schedule 11.08.2015

Ответы (2)


arrow_upward
3
arrow_downward

Перенос приложения в CQRS - непростая задача, и определенно не то, что нужно сделать за один шаг. Однако, если приложение настроено правильно, определенно можно постепенно переходить к (большему) CQRS.

Поскольку ваша задача, похоже, состоит в том, чтобы добавить дополнительную модель представления (модель ElasticSearch), я бы посоветовал начать с публикации событий. В Axon Framework это означало бы определение шины событий и публикацию на ней сообщений.

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

Следующим шагом может быть использование обработчиков команд, командной шины и командных сообщений для изменений, запрошенных вашими интерфейсными компонентами (или компонентами интеграции). Когда они у вас есть, вы можете начать думать о том, чтобы вынести эти компоненты Command Handler в отдельный компонент (используя события для обновления компонентов запроса, которые остались после разделения).

Перед выполнением каждого шага обдумывайте объем работы и реальные преимущества, которые они вам дают. Например, не стоит убирать компоненты обработки команд. Отправка событий из «монолита» уже может дать вам достаточно гибкости для создания вокруг него отдельных компонентов.

person Allard    schedule 21.02.2017
comment
Я действительно проводил веб-семинар по этой теме: youtube.com/watch?v=6YZZo19xStw . Может быть, это поможет дать больше контекста. - person Allard; 21.02.2017

arrow_upward
1
arrow_downward

Просто чтобы поделиться опытом:

  • Я начал с командного шлюза и обработчиков команд для отправки и управления командами в моих контроллерах Spring MVC и планировщиках задач.

  • События также выглядят интересно, однако мне еще предстоит найти способ интегрировать события (без источника событий) в существующий уровень сохраняемости spring-data или mybatis.

Буду признателен, если есть какой-либо пример по этому аспекту :-)

person Ian Lim    schedule 18.04.2015