In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events the

In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events they're hooking into and in which exact order. I’m with you on the first part: finding all possible listeners to a certain event is sometimes useful in the same way that finding all possible callers of a certain function is useful. I’m not so sure about the “which exact order” part, though. IME, this style of architecture works best when you can entirely decouple event listeners and run them asynchronously, so each event listener is unknown to both the original event source and any other event listeners, except for whatever mechanism is used to register as a listener. If you do need an event to trigger multiple actions in different parts of your system in a specific order, then apparently those parts of the system aren’t entirely independent. In that case, I usually suggest creating a single listener somewhere near them to co-ordinate. It might be very simple, but it makes the dependency between the multiple actions explicit, and now you have a single place in your code with responsibility for triggering each action in the required sequence, without imposing any ordering requirements on your entire event-based architecture.