In an event driven system you can start with some safe assumptions:

* Events always publish or they error, so always plan on a global and robust error handling approach.

* Just because an event, or rather its assigned handler, always publishes does not mean it’s either predictable, sequential, or free of side effects. You have to let that tight control go and instead test for results, not execution.

* There are, roughly speaking, only two kinds of events: local and network. Local events may originate from the user or the system but their stack trace is generally reliable and complete, but not so with network events. This becomes more true when the given application is connected peer to peer and thus roles/identity are not clear/distinct.

"Event driven" is also known as "message based". This architecture is really meant for distributed systems. Some variation thereof is about the only practical way to allocate a sub-task to a non-local computing device.

Multi-tasking can be thought of a local inverse of a distributed system. Instead of distributing tasks, it's finite computing capacity that is being distributed to multiple, concurrent tasks.

OOP is yet another case where event driven/message based architecture often pops up. Basically, this is often a mis-guided attempt at simplification by way of sub-task distribution among arbitrary, artificial "objects".

It should be intuitively obvious that event driven architecture is a complication (not a simplification) which should only be applied when there is no better, more practical alternative.

[dead]