The big mistake about EDA

I frequently get questions of people who present me a request-reply scenario and ask me why they for God sake should implement this in an asynchronous way. They come up with all the (performance related) disadvantages of such an implementation. And finally they conclude that EDA may be not such a good idea, looking at me with a big question mark in their eyes.

These people all make one big mistake: they equate the asynchronous implementation pattern to EDA.

It is true that EDA leads to asynchronous patterns, but that doesn't mean that asynchronous patterns are equal to EDA.

EDA is about scenario design, not about scenario implementation. I think EDA as being a business event focused design approach. To me EDA means to start the grand design from recognizing in you business the events that your business planned to react upon. Forget at this level about IT-implementation, but just focus on the event definition. The initial event definition may be deduced from what you currently need to know to appropriately react on this event. Here comes the consuming service(s) to the scene. Next you define the process that detects the event. Here comes the producing service(s) to the scene. The craftsmanship of the designer (or team) is in defining the business event in such a way that it not only fits the current requirements, but also future requirements and out-of-scope usage (event representation reuse in other contexts). This can be accomplished by focusing on the characteristics of the event itself - in impartial isolation - when defining the event, and not on the current known consuming services. The currently foreseen consuming services are only of any help to get to an initial start of defining events.

When you come to define the event-producing and -consuming services you are diving into a more detailed layer of abstraction. It is very well possible (and desirable) to continue the EDA design approach at that level and all lower levels. Depending, however, on the level of abstraction you will start to recognize stronger cohesion in terms of ACID-transactions and dialogs. The deeper you dive, the stronger the cohesion will be. This means, even while still at a functional level, you will start recognizing request-reply mechanisms. This is the level where the big mistake originates from. Implementing such request-reply mechanisms in an asynchronous way may offer advantages with regard to required mediation of the messages and loosely coupled addressing, but it will always be a trade-off with performance issues and available middle-ware infrastructure. Mind that this has nothing to do with EDA.