For the last decade, I have been involved in the design and development of applications in the financial services industry using an architecture which we refer to as an event driven architecture (EDA). However, searching for EDA on the Net shows that the moniker Event Driven Architecture has been taken.

With EDA taken, I started searching for an unambiguous way to describe the business architecture used. And that turned out to be not that easy.

So the basic principles of the architecture (or processing mechanism) is:

    • An action triggers an event on an object.

    • The object checks whether it can currently react to the event

    • The object then chooses how to react to the event. This reaction can be

        ○ a state change

        ○ an action

        ○ Ignoring the event

       Â

The above contains all the elements of a state transition diagram. Some plagiarism on my side, but simple notation used for state-diagrams pasted below

State. A condition during the life of an object in which it satisfies some condition, performs some action, or waits for some event.

Event. An occurrence that may trigger a state transition. Event types include an explicit signal from outside the system, an invocation from inside the system, the passage of a designated period of time, or a designated condition becoming true.

Guard. A boolean expression which, if true, enables an event to cause a transition.

Transition. The change of state within an object.

Action. One or more actions taken by an object in response to a state change.

 

One deviation from the state transition diagram however is that a large number of events actually do not cause a state transition, but normally does cause one or more actions. The action is thus triggered by the event rather than by a state change

So it turns out that the architecture we use is actually an “event driven state transition architecture”.

What we add into this is the ability to configure the following on a per event basis:

    • What validation (guards) to perform, if any

    • What state changes to do, if any

    • What actions to perform, if any

   Â

And therefore we end up with a “configurable event driven state transition architecture”

Then we also add the capability to execute custom algorithms for

    • Validations (guards)

    • State changes

    • Actions

 

Which makes it, I guess, an “extendable configurable event driven state transition architecture”

Quite a mouthful, so if you will excuse me, I will stick to event driven architecture (EDA) for now.

 

But what makes this so special that I actually want to blog about this?

The answer is easy: An engine or model built with this architecture provides an extremely powerful processing capability. So powerful in fact, that I plan to do another blog (or two) on how this provides the power. Then I probably also need to do 10 blogs on how to test it , but for next time , I’m going to focus on the power!