How Events Are Reshaping Modern Systems [video]
infoq.com
infoq.com
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
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.
"Event Driven Services
1. Receive and React (or not) to facts
2. Publish new facts (immutable events)
3. Invert the control flow"
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.
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...
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.
EDIT: forgot to add the publishing date
watchers[0].customerNameChanged(this, old_name, new_name);
emit_for_whomever(new CustomerNameChanged(this,old_name, new_name));
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.
http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Manual-June-1987...
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.