I've worked with event driven architecture and it's always been a nightmare. Essentially, you're reinventing a commit log, about 1/4 of a really shitty custom database. Once you have aggregates you've basically gone full wheel.
Add to that, the fact that normal RPC is "forbidden", so you end up with like 10 copies of each aggregate across various services.
The killer feature is "replays", but trust me, after storing every state change for even a few weeks those replays are going to start taking hours if not days. And your services are all down while they happen.
Pretty soon you start understanding the wisdom of databases not keeping commit logs around forever.
I think it helps to distinguish between (A) event sourcing and (B) systems that emit events as a coordination and communication mechanism only.
In the first case, you're able to do those replays but you also have the pain of somehow controlling the evolution of that system over time, as event-definitions and the consuming code behavior changes constantly.
I think the second case has a lot more "easy wins" and is a better fit for most systems that do not require exhaustive auditing. You might keep all of the events around in a durable store, but they're more like hieroglyphics in a museum than a library book that is constantly retranslated.
How is this different from "objects receive (or ignore) messages, send new messages, invert the control flow"?
Except of course for the new and shiny.
"Mutable State Needs to be Contained (within the service)"
-> (mutable) state is contained within objects
"Use the Event Stream as the Consensus Fabric"
-> TeaTime, David Reed's Multi Version Concurrency Control
etc.
Have we really not understood OO at all so that we have to reinvent it all the time? Or maybe this should be seen as a validation of those principles, because we keep coming back to them even when we don't know it.
> Have we really not understood OO at all so that we have to reinvent it all the time?
We haven't. I think the popular OO languages shows this. In both Java and .Net the focus is on classes, not on messages passed between objects. But class hierarchies are not essential for message passing. Classes are mainly a way of decomposing an application into manageable logical parts of interacting chunks. Looking at how many language features center around classes and class hierarchies (interfaces, abstract classes, generics, inheritance etc) as opposed to how many facilitates different forms of interactions between objects (you basically have method calls and arguably async/await) it seems clear to me that these languages are more "class oriented" than object oriented...
I think it is more a matter of people not understanding their tools.
React UI? Smalltalk already had Observer and event messages.
java.util.Observable exists since version 1.0.
Interfaces are lousily based on Objective-C categories, and the first edition of "Component Software: Beyond Object-Oriented Programming" using Component Pascal, COM, Java was published in 1997.
The second edition added C# examples.
Which are concepts that now everyone is discussing as Entity–Component System.
Our field would be much better if there was less pop culture and more book/paper reading.
The second version actually has more classes being defined and objects being created. However, it comes with quite a few benefits in terms of documentation, duplication, persistence, deferring, batching, etc.
The problem is that whenever we think OO, visions of Alan Kay and Smalltalk float into our heads and suddenly Everything Is An Object. Numbers "know" how to add themselves to other numbers, strings "know" how to print themselves to standard output...
...insanity ensues. We wake up, write a blog post about how OO failed and discard it all, only to repeat the cycle when we notice that some of the sane things we're doing look entirely as if we were doing OO.
This is a highly insightful comment. Thanks! I find the TeaTime stuff fascinating, but is know they only a handful of people have ever heard of it. Do you have any pointers for reference?
Having been involved in the delivery of a complex distributed software system designed using MASCOT, I can attest to it being instrumental in the creation of one of the most robust pieces of software I've ever seen. Consistently topping the System Prime's quarterly metrics for up-time.
Add to that, the fact that normal RPC is "forbidden", so you end up with like 10 copies of each aggregate across various services.
The killer feature is "replays", but trust me, after storing every state change for even a few weeks those replays are going to start taking hours if not days. And your services are all down while they happen.
Pretty soon you start understanding the wisdom of databases not keeping commit logs around forever.
If you value your sanity wait this one out