Small correction for one of the questions at the end, unprocessed messages are NOT lost during restarts. Only the state (if not persistent actor) as well as the current message which may have thrown an exception. For the current message you can handle that in the pre-restart.
I am always on board of trying to do these types of implementations in real life systems but at the end every single one that I have encountered with these Actor and Event design ideas, it is a hell of code base to maintain, really, no one loves it because it feels over engineered. That is on small and large codebases. Only CQRS is the only worth idea that I see people tend to like, and also myself. Thanks for the video!
Frankly speaking, those things are just tools. If you've experienced that codebases using those tools are huge, then it's the developers who failed, not the tools themselves. I work on event-driven systems where event handlers act in an actor-like fashion, and I can say that such an approach contributes greatly to code quality and readability. That's because by orientating the code around events and event handlers, you get single responsibility principle out of the box.
I have not used these strategies in production. In your experience, is the issue the paradigm or the tooling? My understanding is that long lived systems have been written in Erlang without becoming hellish. However, Erlang is built from the ground up for the actor model while Akka is glued on top. Do you think that makes a difference?
Yes, you're correct, it's a hell to maintain. What I've noticed is that, anything with globally shared state or events is a mess in general and actors is both of these. Of course, this does not mean it's bad, but the probability that you will mess up is greatly increased. I viewed a professional project that uses akka, and the only way to understand how code works is to build a mental map of the whole project everytime you open it.
It’s not easy to understand every nuance but he’s even using Functional Event Sourcing Decider pattern and probably no one noticed that. This talk requires knowledge about ddd and event sourcing and of course actor model to have clear understanding because otherwise it’s may be seen as over engineering practices. Anyway this form 1h makes it very shallow and lacks of real world usage example, eg. if your using event sourcing you should to use true event store and tooling around it to manage it. Yes, it’s hard to get the full view of an project created in that manner. Great possibilities but requires lots of knowledge 😊
In the Actor model, an Actor responds to messages passed to it. So an event bus could be an Actor by itself. The problem (from what I understand) about using event bus is that people generally use it to invert dependencies, but this just hides the dependencies. Which in the end just leads to a big ball of mud. EDIT: never mind, he explains the ActorSystem in 19:07. The benefits of the Actor model are too many to summarize in a comment (disadvantages as well). For more info you can search for Elixir and Erlang which are languages that implements the Actor model in all facets via the BEAM vm, even if the creators of BEAM didn't know wtf the Actor model was back when they built it.
