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?