Axon Framework: должны ли микросервисы обмениваться событиями?

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

Я бы сказал, что вы должны рассматривать свои команды / события / запросы как API вашего приложения. Таким образом, может быть полезно поделиться структурой событий с другими проектами, но не с самим POJO. Например, вы можете подумать об использовании ProtoBuf для этого варианта использования, если в ProtoBuf описана схема для ваших событий.

Еще одна вещь, о которой следует подумать, - это не раскрывать весь свой «event-API». Обычно у вас будет довольно много мелкозернистых событий, вещей, которые не интересуют другие (микро) сервисы в вашей среде. Однако всегда есть пара «очень важных событий», иначе говоря, «этапных событий», которые определенно являются другими. интересует. Эти вехи в некоторых сценариях не являются прямым POJO, следующим из вашего домена, а скорее совокупностью нескольких событий.

Таким образом, нередко бывает служба, которая накапливает их и публикует другое событие для уведомления других служб. Накопление этих мелких внутренних событий и публикация контрольного события в качестве ответа на них обычно лучше подходят в качестве API-интерфейса событий в вашей архитектуре микросервисов.

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

Вы правы, «официальное» правило - не делиться моделями. Так что, если у вас есть распределенные команды разработчиков, я бы придерживался этого.

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