What is the right way of using event aggregator/message bus?

Question

Recently I had a conversation with a colleague, who proposed that a whole app could rely on an event aggregator (or message bus).

I think this is a really good pattern if someone wants to decouple publisher and subscriber, especially in cases where we have multiple publishers/subscribers. If there is just one, I think it is perfectly fine to request a service from DI and call a method on it, there is not really a need for event aggregator (but it is fine IMO). Also, if there is request - response, there is not really an event, and maybe someone should use other patterns (e.g. observer pattern).

However, my colleague proposed something much more "drastic" - tunneling the whole app communication through an event aggregator. For instance when the UI wants to know something from DomainEntity it would create the event RequestSomethingFromDomainEntity(id: 37), Then the domain entity would respond with SomethingFromDomainEntity(id: 37, data: data[]).

I see the following pros:

• Such classes are super easy to test, you just generate events
• Basically everything is decoupled from everything (at least semantically)
• Implementing business rules is super easy, because the interactor classes only need to access the event aggregator

And the following cons:

• You do not really know what events the class may expect or produce
• Someone cannot really tell anymore who talks to who in the app, because everything has dependency on the event aggregator and anything can handle messages
• I imagine it is really hard to debug

My questions are:

• Can someone who worked in this style share his thoughts?
• Are there any other pros/cons?
• Do pros outweigh cons?

Answer 1

While what you say here may be true

Basically everything is decoupled from everything (at least semantically)

By having this "God class", you also reduce cohesion because you concentrate too many responsibilities in just one place, often cluttering a single file with many methods. This, combined with the other point you make

Someone cannot really tell anymore who talks to who in the app, because everything has dependency on the event aggregator and anything can handle messages

will make the code difficult to understand and maintain, which leads to your last point

I imagine it is really hard to debug

So, to answer your question

Do pros outweigh cons?

I would argue the opposite (i.e., the cons outweigh the pros). In my opinion, it is best to avoid such classes so you can benefit from the ease of comprehension in your code and promote better and faster development.