Нет, вы рассказываете про проблемы, которые могут произойти если будете использовать скрам и которые вы сами себе выдумали.

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

Параллелей можно проводить много. Сообщение это просто POCO объект.

А интерфейс это просто интерфейс. У вас всё тот же контракт. Просто описаный не интерфейсом а разными классами сообщений. Надо сказать что с EventBus-ом тесты писать даже проще чем с интерфейсами.

А вот что с EventBus-ом плохо так это скалируемость. В смысле роста числа классов сообщений. Сначал их 10, через год 100. Никто нигде не описывает для чего он ввёл сообщение TemperatureIncrement. И мы погрязаем в 2-х антипаттернах:

1. Неправильное повторное использование сообщений.

Разработчик добавляет функцию в управляющий гуй - "изменение температуры срабатывания тревоги". Ему как-то надо от гуя передать модулю мониторинга новое значение. Он находит сообщение TemperatureIncrement и радостно его использует. Конечно же, не тратя н-цать часов на то чтобы проверить а где оно используется сейчас, а кто и при каких условиях его бросает. В результате, модуль получающий сообщение от датчика температуры, видит повышение и кидает TemperatureIncrement, который радостно обрабатывается мониторингом и вместо того, чтобы бить тревогу, просто увеличивает порог срабатывания. Примерно понятно в чем проблема?

2. Дублирование сообщений.

Порывшись в классах сообщений, и не догадавшись что P12RsSig5V это то, что ему нужно, программист делает новое сообщение DoorOpened (которое и посылается когда на 12-м пине повышается напряжение до 5 вольт).

В результате половина приложения ловит старый P12RsSig5V, другая - DoorOpened. И выяснение почему у нас отрытие одной двери обрабатывается так, а другой - этак становится очень увлекательным занятием.

Да, я понимаю, у вас такого никогда не было и не будет, потому что над проектами работает один человек 1-2 месяца.