You might think the title of this post is purely semantic? Surely if you are using events to trigger functionality, it doesn’t matter so much. James, you’re spending your time writing about something that doesn’t matter.
Until it does.
In his bestselling 2014 book Homosapiens, Yuval Hoah Harari discusses a history of humankind. And one of the key takeaways from that book is the importance of stories. Stories, and our use of words, are what set us apart as a species. Our ability to collaborate at scale, behind a single idea is what makes us different to the animals. Wether that be religion, nationality or the company you work for. These are all human constructs, detailed using language.
Homo sapiens rules the world because it is the only animal that can believe in things that exist purely in its own imagination, such as gods, states, money, and human rights.
Yes, animals work together. But it’s a far more primitive, survivalist kind of collaboration.
So if languages and words are fundamental to human success. And software development is (at least for now, hello GenAI) a human endeavour. The language and words we use in our software is vitally important.
And this is why this distinction is important.
What Is Event Driven Architecture? Event Driven Architecture, in my opinion, is a way of modelling the integration between your systems. And you model this integration using business events. And by business events, I mean things that are meaningful to your business.
Event Driven Architecture allows the language of your business to drive it’s technical implementation - James Eastham
You could look at two businesses in the same domain both building event-driven software. And the set of events in each system could be completely different.
There will be similarities, in function and conceptual ideas, but the language that each of the businesses use will be different. Meaning the events driving the functionality will also be different.
What Is Event Based Software? Triggering functionality via events is not a new thing in software. I started out writing software in Windows Forms. For all you non .NET developers out there, Windows Forms is an old way of building desktop applications for Windows.
Functionality in Windows Forms is driven by events. But these aren’t events that are unique to your business. They are things like ButtonClicked, MouseHovered or WindowResized.
You could look at two systems in the same domain and if they were event based they would have the same set of events. ButtonClicked, MouseHovered so on and so forth.
To bring this into modern, cloud based systems you could look at an S3ObjectCreated in the same way. This is a technical event, that notifies you of a technical thing that has happened. But how many non-technical people in your business would understand what that means?
Who Cares? This might still lead you to ask the question, who cares? If systems are triggering functionality with events, why do the semantics matter.
From a technical perspective, you’d be correct. Both things are immutable facts, notifications of things that have happened somewhere else in the system.
But how many of you have sat in a room with a non-technical person, talking about microservices, REST API’s and SQL databases and had the other persons eyes glaze over? Maybe they mutter under their breaths about ’these nerds talking techie all the time’ and nobody can agree about exactly what the system should do.
Yeah, this is why you should care.
S3ObjectCreated gives you the same problem. This is not the language of your business. InvoiceFileUploaded… now you’re talking.
One of the key takeaways from running an event storming session is to agree on a shared language across your entire business. From technical to non-technical. Don’t waste all that effort by then using different, technical words in your system.
In the same way Domain Driven Design gave us a shared language to talk about our architecture. Event Driven Architecture gives you a shared language to talk about communication. And in my opinion, that’s the real benefit of event driven systems.
The takeaway from this, albeit short rambling stream of consciousness, is to be careful when you talk about being event driven. At it’s core, event driven architecture is about communication. Wether that be technical communication between two services, or the human communication between two people.
Event Driven Architecture allows the language of your business to drive it’s technical implementation - James Eastham
This is the first of a shorter selection of memos I’ll be publishing over the next few weeks. Gathering together my thinking around event driven architecture.
I find writing a key part of developing my own thoughts, so if things get a little messy. I apologies in advance ;)