Есть ли какой-то конкретный способ миграции Axon с версии 2.4.3 на 3.1.1?

В настоящее время нет официального руководства по миграции с Axon 2.x на 3.x, хотя оно находится в очереди на выпуск. Однако я могу дать вам несколько советов, на которые следует обратить внимание при миграции:

1. AbstractAnnotatedAggregateRoot больше не требуется для ваших агрегатов, поэтому удалите его.
2. Публикация событий в ваших агрегатах теперь выполняется с помощью статической функции AggregateLifecycle.apply(), поэтому импортируйте ее.
3. AbstractAnnotatedSaga больше не нужен для ваших саг, поэтому удалите его.
4. Если в приложении Spring, рекомендуется использовать аннотацию @Aggregate для ваших агрегатов, чтобы уведомить Spring о создании всех необходимых bean-компонентов (репозиторий, фабрика ,,,) для агрегата.
5. Если в приложении Spring, рекомендуется использовать аннотацию @Saga в ваших сагах, чтобы уведомить Spring о создании всех необходимых bean-компонентов (репозиторий, менеджер ,,,) для саги.
6. В таблицу domain_event_entry добавлен столбец globalIndex, который, если у вас уже есть несколько событий, необходимо правильно перенести. Этот пост дает некоторое представление о том, как пользователь Axon Framework решает эту проблему.
7. В Axon 2.x у вас было понятие кластеров, в которых вы могли сгруппировать свои компоненты обработки событий. Это было заменено группами обработки событий, в которых у вас есть возможность выбирать между SubscribingEventProcessor (push-событиями для обработки событий). Компоненты) и TrackingEventProcessor (события извлечения сохраняются и обрабатываются в ваших компонентах обработки событий).
8. В смеси Spring / Axon 2.x вы, возможно, использовали конфигурацию через Spring XML. В 3.x вы можете использовать (1) Configurer API, (2) использовать аннотацию @EnableAxon в классе конфигурации Spring или (3 - рекомендуется) использовать зависимость axon-spring-boot-starter для автоматического получения всех ваших компонентов Axon.

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

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

Обновить

Этот бит касается конкретных классов, которые вам не хватает при обновлении с 2.4.3 до 3.1.1:

Как я уже говорил в своем предыдущем ответе, точнее, подпунктом 7, полный кластерный подход в Axon 2.x был заменен подходом обработчика событий в Axon 3.x. Концептуально здесь мало что изменилось, однако внутренне он ведет себя иначе и намеренно более лаконичен. Итак, краткий ответ: все эти классы были заменены обработчиком событий, для которого документация здесь.

Поскольку это совсем не помогает, я дам вам конкретный ответ на классы, которые вам не хватает, чтобы помочь вам. Это довольно долго, так что будьте готовы:

• ClusteringEventBus: Это было сделано для публикации событий в кластере компонентов обработки событий. В Axon 3.x это теперь находится за группой обработки, управляемой реализацией подписки или отслеживания. Следовательно, не ищите ClusteringEventBus для публикации событий в группах. Все реализации 3.x EventBus будут знать, как публиковать события в SubscribingEventProcessor, в то время как TrackingEventProcessor будет извлекать события из самого хранилища (так что шины не задействованы).
• DefaultClusterSelector: Селектор кластера отвечал за группировку компонентов обработки событий / прослушивателей событий в кластер. Как совместно используемые, мы больше не рассматриваем набор прослушивателей событий как кластер, а как группу обработки. Поведение в 3.x таково, что имя пакета реализации прослушивателя событий является именем используемой группы обработки. Однако вы можете перезаписать это, но добавив @ProcessingGroup({processing-group-name}) в качестве аннотации уровня класса к вашей реализации прослушивателя событий. Конфигурация Axon 3.x автоматически сгруппирует прослушиватели событий с одним и тем же именем группы обработки под одним и тем же процессором событий (который в версии 2.4.x будет транслироваться в один и тот же кластер). По умолчанию в качестве реализации обработчика событий используется подписка. Это можно настроить на отслеживание в конфигурации.
• SimpleCluster: Как следует из моего более раннего объяснения, SimpleCluster больше не существует. Он был заменен интерфейсом EventProcessor, который реализуется обработчиками событий подписки и отслеживания.
• EventBusTerminal: EventBusTerminal отвечал за публикацию событий в нужных кластерах, пусть локальных или удаленных. В общем, у нас больше не кластер, а группы обработчиков событий. Как события попадают в обработчик событий, зависит от используемой реализации. Если используется подписка (читай: обработчик событий по умолчанию), EventBus отвечает за публикацию им событий. Однако TrackingEventProcessor будет асинхронно запускать свои собственные потоки, чтобы извлекать события из EventStore и на месте отправлять эти события своим прослушивателям событий. Таким образом, вам больше не нужно искать EventBusTerminal, поскольку он устарел.
• SpringAMQPTerminal: Как я уже говорил выше, EventBusTerminal был удален в пользу подхода подписки или отслеживания. Начиная с Axon 3.1.1, для Spring AMQP у нас есть реализация обработчика событий подписки для прослушивания событий и их публикации в очереди, то есть SpringAMQPPublisher.
• SpringAMQPConsumerConfiguration: Этот класс конфигурации был на месте, потому что когда был представлен axon-amqp, Spring не создавал ListenerContainers, как это было при вводе Axon 3.x. Поэтому было решено не сохранять нашу собственную конфигурацию для этих потребителей и оставить это в компетентных руках Spring. Следовательно, вы не найдете SpringAMQPConsumerConfiguration и должны поискать, как Spring создает потребителей для AMQP.
• ListenerContainerLifecycleManager: Этот класс был реализацией, чтобы правильно принимать все события, поступающие из очередей, и отправлять их всем вашим слушателям событий. Этот класс был заменен на SpringAMQPMessageSource.

Надеюсь, это даст вам ответы, которые вы ищете @AS!