> I fail to see how his process has this problem and yours magically doesn't. You're making a lot of hay out of whether his "reactive" events or your "imperative" messages are better or worse, but they're the same thing: sending messages. The only difference is whether broadcast is better than a direct message sent to a unit.

No, that's not the only difference. Notice that I have 4 actors, only one is burdened with knowing how the process works. Here's what the other 3 actors see from their PoV:

- PaymentActor gets "process payment" event.

- FraudCheckActor gets "check for fraud" event.

- CancelOrderActor gets "cancel order" event.

This is what I call decoupling. 3/4 of your system is completely isolated from each other and reusable in different business processes. And the one actor who is "burdened" with knowing about the process (OrderActor) is in fact, responsible for the process (and you can open its code in one place, read it, reason about it, and change it in one place, not all over the graph).

And his model:

- PaymentActor gets "new order" event.

- FraudCheckActor gets "payment complete event" event.

- CancelOrderActor gets "fraud detected" event.

Those 3 processes are coupled with each other, as they need to interpret each other's events.

If you want to move to another system where the fraud check doesn't happen right after the payment, you need to edit the FraudCheckActor's "reaction" to that event.

In my case FraudCheckActor is only reacting to the "check for fraud" event and so it doesn't have to have its reaction code edited.

There's nothing "magical" about it, just better concern isolation. If you still see this as the same, that's all I could do to explain things :)