Event Driven Architecture... but aren't events just a technical detail?

[Sebastian Gozin]

I may be conflating events with messages but as far as I know an event driven architecture will use some kind of message processing system.

In the past I worked on a system where we would generate a lot of events. And these events would in turn generate more events and so on. It worked, it was well tested. We ran into the occasional difficulty when dealing with an asynchronous system and multi-step workflows but we handled them.

Yet, in the end I'm not sure I was that happy with it. Something started bothering me about it over time.

Consider the following abstraction:

<A> BankAccount

------------------------------

+ withdraw(amount)

+ deposit(amount)

+ checkBalance():amount

Of course you would make a real implementation that does the actual work.

But when you want to make this system available to remote systems you might create a BankAccountClient variant which will use a webservice of some kind to send the instructions over the network.

Then you would need some kind of controller on the server which listens to for example the /withdraw route. Now this controller just needs the real instance of BankAccount and invoke the withdraw method with the amount it parsed from the request.

Now, let's consider using a message delivery system instead of a webservice. This time your client will simply create a data structure like WithDrawFromBankAccount with an amount on it and submit it to the mailbox of the message system. Then on the server a message listener, which often looks very similar to a webservice controller, will receive the WithDrawFromBankAccount data structure and... I suppose just call BankAccount.withdraw(amount)

Now let's say post withdrawal a few other systems need to do something.

Well, I suppose I could write a variant of BankAccount which delegates to the real BankAccount and afterwards invokes those other systems using their respective abstractions.

And if I was a little smarter those abstractions could just be implementations which create a date structure that's submitted to a message processing system.

So...

At this point I only see the events or messages appear in the remoting/transport layer of my system. Which suggests that they are just a technical detail that I may or may not choose to use depending on the benefits and drawbacks of such an approach.

For example, keeping a journal of those events and being able to replay the journal seems like a very interesting benefit. But I don't see how any of that including the events themselves need to be known to the base application.

So I don't see the benefit of an event driven architecture.

Meaning I don't see the benefit of thinking about the system in events or for the most important interface of the application to be a mailbox. I do see the benefit in using events. But I'd still keep them behind the traditional abstractions.

Another perhaps less important reason that makes me feel this way is that it is very easy in an IDE to use a key combination on the BankAccount interface or any of it's methods and get a list of all the variants that implement it. Then based on the names of the variants I'll be quickly able to separate the technical variants from the real one and reason about the system.

If I have a data structure like WithDrawFromBankAccount I can't do anything similar. All I can do is a usage search at which point I'll get a list of places where it is used that includes import statements, instantiations, tests and finally the methods in which it is used as a parameter. Usually in a much less convenient format in which to find your way.

Finally... let me make a comparison that I feel illustrates the difference between the 2.

When 2 people are engaged in a vocal conversation in the traditional architecture you would speak what you have to say and the other would hear it. In the event driven architecture you would type out what you want to say in a text2voice application and press enter to have it speak the words for you.

It seems to me just speaking is a lot more natural. Even if what I've spoken is then converted to a digital signal that is sent over some kind of combination of air waves, optical- and copper cables and converted back to sound by a speaker.