Event Driven Architecture

Event-Driven Architecture is used to describe many different implementation styles. First, let me provide a sequence of how it came about.

Stage 1: Input/Processing/Output

This is the way we viewed computing when everything was Batch. At the beginning of the program you initialized the program, then you read one input record processed it and outputted a resulting record. In this view of IT, an event like a cashed check is an Input.

In the beginning, this model served us very well for what we were doing at the time, like batch updating bank master client records with all checks cashed that day. But as computer hardware performance increased we automated more and more. Soon the Batch Update was processing a multitude of inputs like checks, ATM withdrawals, deposits, savings accounts, interest accruals, automatic overdraft transfers from savings, etc…

The Input/Processing/Output view of IT was failing us. The Processing had to have a huge switch statement to discover the type of input and the state of the account to choose the processing to be done. This created huge complex monolithic pieces of code where everything was interdependent. It was interdependent because the states of the accounts in the system where hidden in processing code and chosen ad-hoc by programmers.

Stage 2: Formal State Machines

We realized that each Process for an Input was a uniquely identifiable unit of work but the decision of when to execute that unit of work was dependant upon the input but also on previous inputs i.e. the state of the accounts.

As we documented this, lo and behold, our documentation was starting to look like state-transition diagrams with each possible input being an identifiable Event that kicked off a specific unit of work and possibly making a state-transition.

Stage 3: Event-Driven Architecture

Now we could master the huge monolithic update programs and we could now see how to implement transactions on the fly. We could now see what code was going to run in the batch, and execute it during the capture of the actual transaction instead of in batch later tonight. When we did this, we called it Event-Driven and we invented system architectures to support it.

What Is It and Why Use It?

Lots of people interpret Event-Driven Architecture to be a specific implementation method of Stage 3. Some will require different physical execution units or separation of source code. A lot of these implementations require certain transaction characteristics. I chose to answer “what is it and why to use it?” with an explanation that gives you a deeper understanding of where it comes from and what it does, and why it is used.

You use it when it is advantageous to your implementation. That is when you have described/defined your system with state transition diagrams, then you can consider implementing the code in an architecture that directly implements it. This would allow you to separate your code into applicational divisions or domains, such as a Universal Notification Servers, ATM front ends, checking accounts, bookkeeping, etc. This will greatly reduce the amount of domain knowledge your individual programmers need to manage.

When Not To Use It

In order for the system to work the Events need to contain Business Context, a transfer of money from one account to another in a bank is a good example, it can be done more or less independently of how the input was generated. (within the constraints of your transaction architecture) but when the event is passed to bookkeeping more information is required, specifically if the transfer represents an Active or Passive transaction. This Business Context needs to be coded in your Events so that bookkeeping can process the event independently. This requires careful design of the state transition system you are implementing and requires that everyone understands the different events and when to issue them. If you cannot do that you are not going to get the promised benefits of Event-Driven Architecture.