Whether you like it or not, all of us, including you and I; are constantly influenced by external factors. We often think of our own view as the least subjective one, but that's rarely the case. Our own view is rarely as objective as we'd like to think.
The same principles apply in the world of programming: developers focus on one framework, one language, one ecosystem, and often think that their way of doing things is somehow the best.
One of the most obvious examples of this in my personal life goes back to the very root of web development. Almost as soon as I started programming, I was taught about MVC frameworks where I use a database to store my application's state in. I was, in fact, programming web applications in a way that was generally considered as "the way to go"—no questions asked.
When event sourcing was first explained to me, I had difficulties understanding it. Even after I learned the basics, it was still difficult for me to accept that this could be an equally valid approach to solve my problems. Maybe it had to do with the way it was explained to me, but I remember leaving my first event sourcing talk thinking "this will never work in a traditional web app".
Years later, I realized it was my own short-sightedness that was the limiting factor. My personal education and practice made it difficult to consider event sourcing as a solution to my problems.
I can now admit that I was wrong.
I want to tell you a little about how I came to that realization, and how event sourcing has changed the way I think about programming forever.
I'm a PHP developer. It's a language that has gotten a rather bad reputation over the years, but has been growing into a mature language and ecosystem for the past five years or so. It really isn't the same language it was ten years ago, and I am very thankful for that!
Within the majority of the PHP community, event sourcing is still some kind of magical beast. No surprises there: most of us have been taught one style of programming for the web and never even considered alternatives.
I remember having a vivid discussion with one of my colleagues, where I explained to him how event-driven systems are a bad idea: the indirectness between events and their handlers creates a complex web of program flow that was hard to debug and maintain. I doubted there would be any case in which the benefits of an event-driven system would outweigh all the downsides I saw.
Fast-forward a year, and I'm asked to help design the architecture of our next big client project. One of its requirements was that they wanted to generate reports based on historical data, but they couldn't tell us yet what those report exactly would look like. We'd need to be able to add new ones even after we've gone to production.
It's a classic use case for an event sourced system, and we knew it.
Instead of further fighting the idea, we decided to dive right in—mind you, not into coding but into researching the topic. What followed were two months of extensive learning and pair programming, trying and failing and starting again.
One important insight came early on: Greg Young talked about how event sourcing doesn't require a complex framework, it's more a state of mind. The technical setup for event sourcing isn't that difficult actually; it's more about what we do with the concept of storing and replaying events, rather than how and where they are stored or replayed.
The second insight was the true game changer: event-driven systems model the real world much better than other architectures. Everything that happens in our lives isn't represented by a table holding the "current state". It's the sequence of events that brought us to a certain point. While I disliked events at first because of their indirectness, it's that same indirectness that's the reality of life. Why would we fight that reality?
The perfect examples of this principle are all around us: many industries in fact use the concept of event sourcing (albeit often outside of programming): accounting, banking, bookings; you name it, most industries already work in an event-driven way. Why should our code to manage their systems deviate from that?
A final realization was that event sourcing doesn't have to be the solution to all problems. My biggest fear going in this new client project was that everything needed to be event sourced. It was again Greg Young who explained how this train of thought was "the single biggest bad thing that he'd seen being done with event sourcing". Once again I was influenced by my prior knowledge and education and was thinking too much about building a monolithic application. Instead, I'd needed to think of it as multiple services working together (even though they could still live in the same codebase). We are fairly certain that a true microservice architecture would have been overkill for this specific project; but nevertheless, many aspects of the "microservices mindset" were helpful in designing this project.
Do you know that feeling when you're writing a complex piece of code and all of it just falls perfectly in place? Like pieces of a puzzle suddenly fitting together and allow you to see the big picture. I've had that feeling several times a day when I started working on event-driven systems. My colleagues have had to listen to me going on about the beauty of the code we were writing over and over again.
I consider myself to be rather sceptical, so I'm not exaggerating when I say that event-driven design and event sourcing have truly been the biggest revelations in my programming career. I'm even so passionate about the topic that I decided to write a book about event sourcing and event-driven design for the PHP community. I want to share my excitement, and teach people how simple the principles actually are. The book isn't finished yet, but you can subscribe for updates on it here.
I want to end with a closing thought: even if you have no plans on using event sourcing any time soon, it's worth learning about it. It will give you a whole new view on programming and designing systems, and that in itself is worthwhile.