вот событие <модуль импорта запущен> - это ЖЦ-приложения
<импорт документа завершен> - ЖЦ бизнес-процесса

например перед стартом модуля импорта я хочу кое-что подготовить

тут эвент паблишер и листенер ок

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

я вижу это так

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

с этим согласен

А задача у @nixel2007 как раз про аспекты, а не про очереди 😊

Единственное, что мне кажется странным в решении - раздавать this изнутри себя самого, если ты не builder и специально не заточен под мутацию.

не, речь не про код аспекта. вот есть у меня бин1, который используется где-то вовне. аспект следит за методом на этом бине1. бин1 внутри себя инжектит какой-то другой бин2. внешний объект вызывает эдвайснутый метод на бин1 (он по честному обернут в аоп-прокси), бин2 вызывает эдвайснутый метод на бин1 (а здесь пришел оригинальный this). первый вызов ловится аспектом, второй - нет

эвенты синхронные, и обработка этих эвентов тоже нужна синхронная, так что очереди не совсем подойдут

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

Что-то вы, парни, перемудрили с этим, мне кажется. Отдавать this куда-то налево, хрен пойми кому, которые у тебя хрен пойми когда что-то могут вызвать - это смело 😊

я могу рассказать конкретнее, если нужно)

На проекте наткнулся на такой код

                                             kafkaProducerTemplateLock.readLock().lock();
    try
    {
      kafkaTemplate.send(topic, key, eventPayload);
    }
    finally
    {
      kafkaProducerTemplateLock.readLock().unlock();
    }

Кто нибудь знает, зачем надо лочить отправку сообщений?

Я, конечно, могу побыть уточкой 🦆 но не сегодня 😊 Просто сами подумайте, какую задачу вы решаете и нет ли уже готовых шаблонов под это дело?

спасибо) над текущим вариантом тоже долго думали. в любом случае, спасибо за дискуссию и попытку помочь!

                                             kafkaProducerTemplateLock.readLock().lock();
    try
    {
      kafkaTemplate.send(topic, key, eventPayload);
    }
    finally
    {
      kafkaProducerTemplateLock.readLock().unlock();
    }

Скорее всего бессмысленная затея. Во-первых, KafkaTemplate можно использовать из разных потоков, во-вторых, метод send() вообще асинхронный, там почти ничего не происходит

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

Ну, если поле kafkaTemplate не final и меняется, тогда, наверное, оправдано