EDA is based on the concepts of events, publishers, and subscribers. At the most basic level, the idea behind EDA is that publishers publish events and subscribers consume them. Of course, some logic and rules must be applied to properly route the events. Through this mechanism, systems become connected in a loosely coupled fashion. This makes the integrations a lot easier and eliminates the need for each publisher and subscriber to know the details of how to communicate with each other.
Sounds familiar? Absolutely! Change the terms events, publishers, and subscribers to services, providers, and consumers respectively and the paragraph above reads like an explanation of SOA. Why is this, you would ask? Because EDA is nothing more than an asynchronous version of SOA. The major difference between the two is that services are typically implemented as real time calls while events are published and consumed asynchronously. All the other concepts are virtually the same.
While the architectural approaches and design patterns for EDA are slightly different from SOA, the fundamental concepts are still the same. A central event handling infrastructure that knows how to receive, route, and transform the messages is required. It should be viewed as practically the same thing as the Enterprise Service Bus (ESB). In fact, generically, I would call it the Enterprise Eventing Bus (EEB). As events are published, they need to be translated into a common representation, so that a consistent set of rules and operations can be applied to them. A canonical model is the best solution to achieve this goal. Additionally, the same façade pattern should be used as described in the SOA Façade Pattern post to abstract the publishers from knowing and being tied directly to the Enterprise Canonical Model. Note that the logical EDA architecture presented below is very similar to the one introduced in the SOA Façade Pattern.