Usually, in an event-driven architecture, events are emitted by one service and listened to by many (1:n). But what if it's the other way around? If one service needs to listen to events from many other services? I know many people would then use a command - for a command a n:1 relationship, i.e. a service receiving commands from many other services, is quite natural. Of course that's not event-driven anymore then. Or is it.. what if the command doesn't require a response? Then again, why is it a command in the first place, maybe we can have n:1 events instead?

What's your experience with this, how do you solve it in your system if a service needs to listen to events from many other services?

Interesting way of looking at it. The way I’ve usually seen it is by modeling events more like “classes” where an event has a “type” and can inherit other “types” or “interfaces”. So if you want a notification to go out with a domain event, it must implement the “notify” interface.

Commands don’t belong on an event bus though, IMHO. Commands are method calls (or RPC) not messages.