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

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?