You should stop and first think about your big picture goals. What is the source and timescale of your events? What is the lifecycle of higher order processes you build using event cascades? What are your reliability, durability, and recovery concerns? Get to know your concerns before you start seriously evaluating any tools or design approach. But, before you go too far in this thought process, wander over to the "you cannot have exactly-once delivery" thread and think on that for a while too.
Distributed reliability or consistency goals may lead you away from event-driven and into state-driven approaches. You start to model the actual long-term process you want managed, and the producers and consumers can inspect or update a metadata record representing that process as they play their parts in it. I.e. you are better off with some idempotent order-placement protocol to create a customer order record than some simplistic "customer clicked order button" event which could leave to ambiguous scenarios where orders are placed, lost, or duplicated. Similarly, you don't want abnormalities in your fulfillment process to introduce more ambiguity as to whether an order has been shipped or not. This is where "business process" or "document process" frameworks would be more appropriate than event-driven ones. Such systems may have event-driven characteristics in them, but that's more of a scheduling optimization and not the fundamental state model.
On the other end of the spectrum, you can have sensor-based systems where measurement samples are streamed. You cannot have the monitored environment pause until a sample is registered. You can only observe or fail to observe the environment while it continued on its natural course. You really want some kind of capture, logging, and analysis platform. It would be inappropriate to treat the individual samples as events in an EDA, but you might synthesize events from an analysis, i.e. when a measurement value crosses some threshold or shows some time-dependent signature across multiple samples.
Distributed reliability or consistency goals may lead you away from event-driven and into state-driven approaches. You start to model the actual long-term process you want managed, and the producers and consumers can inspect or update a metadata record representing that process as they play their parts in it. I.e. you are better off with some idempotent order-placement protocol to create a customer order record than some simplistic "customer clicked order button" event which could leave to ambiguous scenarios where orders are placed, lost, or duplicated. Similarly, you don't want abnormalities in your fulfillment process to introduce more ambiguity as to whether an order has been shipped or not. This is where "business process" or "document process" frameworks would be more appropriate than event-driven ones. Such systems may have event-driven characteristics in them, but that's more of a scheduling optimization and not the fundamental state model.
On the other end of the spectrum, you can have sensor-based systems where measurement samples are streamed. You cannot have the monitored environment pause until a sample is registered. You can only observe or fail to observe the environment while it continued on its natural course. You really want some kind of capture, logging, and analysis platform. It would be inappropriate to treat the individual samples as events in an EDA, but you might synthesize events from an analysis, i.e. when a measurement value crosses some threshold or shows some time-dependent signature across multiple samples.