Hi Farrel, you are totally true that engineers need take their own responsibility as well and don't rush into something head first and hope they come out the other end in one piece.

I am specifically referring to Event Sourcing, not event driven architectures. The reason my diagram also has a dash of event driven in there is that in many Event Sourcing architectures CQRS is implemented with some form of event-based pub/sub to broadcast state changes to so that the various read-stores are updated.

While using event driven architectures also introduces some challenges like at-least-once-delivery and event ordering (depending on use cases) the important difference is that in event driven architectures events are not used as a means to durably capture and record the system's state. Instead in that context events are used to trigger an action in the system, and carry some data that is beneficial for executing that action. The system's state is still captures in a separate datastore like a database.

So, components reacting to event don't have to understand every version of event ever made like they do with Event Sourcing, just the most recent one (and minus 1 for robustness and zero downtime deployments). This differences is huge difference in complexity. Big fan of event-driven-architecture.