Каркас для Event-Driven программирования

Использовал подобный подход на android — он там имеет дополнительные плюсы, так с UI можно работать только из основного потока, и реализован функциона передачи ивентов между UI-потоком и тред-пулом. Используется Roboguice для dependency injection.
Реализация:
GlobalEventManager
https://gist.github.com/naphaso/c9dbb8a4d4035d1f0584
умеет регистрировать/разрегистрировать обработчики сообщений с определённым типом TP — обрабатывать в тредпуле, UI — обабатывать в UI-потоке, IN — обрабатывать синхронно в потоке, пославшем сообщения (значительно быстрее, если обработчик сообщения отрабатывает очень быстро и не взаимодействует с UI).
Отнаследованы и подкручены тред-пулы, чтобы назначали красивые имена тредам, которые обрабатывают сообщения, чтобы было видно в логах, к обработке какого сообщения отновится каждая запись там.
EventTask
https://gist.github.com/naphaso/69de1a51ad383035dd04
Собственно, он и назначает красивые имена тредам.
EventListener
https://gist.github.com/naphaso/cc6d7b5da4de4c301f8d
Хранит WeakReference не объект и метод для обработки сообщения. WeakReference — чтобы, в случае, если объект забыл или физически не может (не знает, когда) отписться от приёма сообщений, это не приводило к трагическим последствиям в виде удерживания этого объекта в памяти.

Используется примерно так:
В любом объекте при его старте подписываемся на сообщения:

globalEventListener.registerListeners(this);

Когда уже не нужно принимать сообщения, отписываемся:

globalEventManager.unregisterListeners(this);

Как уже сказал, отписываться не обязательно, но желательно.

Обрабатываем сообщения в методах, аннотиованных следующим образом:

@Event(ThreadType.UI)
public void onSomeEvent(SomeEvent event) {
    // some UI work
}

Ну, и полный пример:

@Singleton
public class SomeBackground {
    @Inject
    private GlobalEventManager globalEventManager;

    @Inject
    public void init() {
        globalEventManager.registerListeners(this);
    }

    @Event(ThreadType.TP)
    public void onStartBackgroundWork(BackgroundTaskEvent event) {
        // some work
        globalEventManager.fire(new PublishResultsEvent(results));
    }
}

public class SomeActivity extends RoboActivity {
    @Inject
    private GlobalEventManager globalEventManager;
    
    @Override
    public void onCreate(Context context) {
        super.onCreate(context);
        globalEventManager.registerListeners(this);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        globalEventManager.unregisterListeners(this);
    }

    public void onButtonClickListener() {
        globalEventManager.fire(new BackgroundTaskEvent(...));
    }

    @Event(ThreadType.UI)
    public void onShowResults(PublishResultsEvent event) {
        // show results in GUI
    }
}

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

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

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

Велосипед?

code.google.com/p/guava-libraries/wiki/EventBusExplained
code.google.com/p/simpleeventbus/

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

Как уже ответили выше, Вы изобрели велосипед, под названием EventBus. Есть много имплементаций, например, из Guava. Событийное программирование — это огромный антипаттерн, который использовать нужно с особой осторожностью, а по возможности избегать вообще.