Event Driven Architecture — a magic approach that should matter to your business

Many developers pay attention to technical details: patterns, architecture, frameworks etc., neglecting business aspects. That’s development for development’s sake. I believe that only when developers understand what matters to the business, its challenges and needs, are they able to choose the right solutions. That’s why one of my favourite ways to think of business applications is to consider them as a set of events — a magic approach called Event Driven Architecture.

What are events?

The concept “event” is used in Domain Driven Design methodology (which I’ve explained in my previous article about DDD: What I learned from using Event Driven Architecture and DDD).

Events are changes in the state of the application expressed in past tense, e.g. InvoiceCreated, InvoiceItemAdded, InvoiceSent. They describe everything that happens in the flow of the system from business perspective. Events are independent of system implementation and technologies. Also, thanks to the natural way of naming events, it’s easier for tech and business teams to make sure they’re talking about the same thing.

How to start?

It might feel scary to start using a new project methodology right away and use all its concepts and tools properly. But there are a few elements you can introduce almost from the spot on. These are:

• Event storming
• Ubiquitous language
• Event sourcing
• Event Driven Architecture

Event storming and ubiquitous language

We already know that in order to build a useful system, we need to understand the business domain. Our clients are domain experts who can introduce us to the status quo, challenges, and a vision how to overcome them.

One of the ways to do it is called event storming. It is a moderated session with everyone involved. A moderator makes sure participants are engaged and on the same page.

Events, actors and aggregates

First, the group builds a model of the system flow using events. In front of a big wall each participant:

• picks a post-it card,
• writes down a domain behaviour in a past tense (that’s the “event”),
• sticks it on the wall in the correct order.

The post-it cards from left (the earliest) to right (the latest) show the order in which events appear in the application.

Let’s take the event UserRegistered as an example. When we have it on the wall it’s time to add commands. They’re triggers that make the event happen, e.g. RegisterUser.

The second step is to add a person who executes commands, called an actor. A WebshopUser can be an example of an actor. Finally, participants divide commands, events, and actors into groups called aggregates, e.g. Account.

A result of an event storming session is a full flow diagram (in other words: domain), independent of the infrastructure and architecture.

Watch your language

Event storming naturally adopts one of the rules of DDD called ubiquitous language, which is using the same names on the business side and in the code. For example, when the business owner says that a problem appeared when the package was sent, he refers to the state called PackageSent. We know exactly to which part of our code they’re referring to. I can’t stress enough how much easier it is then for a developer to talk to the client and avoid confusion.

In general, using the same language and definitions on the business and tech side is a valuable lesson all project teams can take from DDD. The system reflects 1:1 what’s in the business.

Event Sourcing / Event Driven Architecture

In a regular application architecture we insert and fetch data from the same database. The majority of event sourced applications use two databases — Event Store for storing events and Read Model. You’re asking for particular data from the read model database. The main state of an app is stored in the event store as a set of events. So Read Model is a sort of projection for Event Store.

Whenever an event is applied into Event Store a specific mechanism (e.g projector, normalizer, etc.) synchronizes the state in Read Model.

The crucial characteristic of Event Sourcing is that it guarantees all changes to the domain (state) are initiated by the events. Thanks to this approach, we can gain some useful features like:

• Event log: stores every single change of the state in the system across time, so it’s clear what has been happening with a specific user from the beginning. In consequence, it is possible to print every single action of this user in the system.
• Better debugging: debugging becomes much easier, because it’s clear what exactly happened in the system, when it happened, and it’s possible to link it with a bug occurrence.
• Restore the state: recreates application state by applying the events from the event store.
• Handling side effects: each event from Event Store can be a trigger for new events, e.g. for sending an email to a newly created user.

Clear and concise architecture

When looking into the code of a DDD-based application it’s possible to see a lot of different layers. At the first glance, it may seem there are too many layers, but they’re there for a reason. They put events in order. It’s better to have more layers than fewer, because then you know exactly where in the chain of events a piece of code belongs. This way the code becomes more maintainable and easier to develop even for a big team. This flow suits all development cases — everything can be handled as an event.

What’s also interesting, by using the flow of events we can secure sensitive actions in an application. For example, checkout may be treated as a checklist of events that need to occur to complete the purchase process.

Summary

Why should business care about events, then? Because all the methodologies, patterns and architectures connected with them lead to better business understanding for everyone involved. This facilitates communication and collection of business requirements — it’s possible to deliver features faster and create foolproof solutions.

As a result, the risk of burning the budget decreases, which can be especially important for startups. Because, in the end, what really matters is cashflow!

Originally published at www.briisk.co on September 6, 2018.