> 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).
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 :)
I feel like this would be a much better discussion somewhere else—i have no idea whether you're still reading this thread. :)
I get what you're saying. The way I write my systems when doing evented/reactive logic is that there is a layer between the event and the message to, say, the FraudActor, responsible for mediating between domain events from different bounded contexts (to appropriate a term from DDD) and the system in question.
The main criticism I have about your methodology is that I reject the notion that the OrderActor should be responsible for sending messages to the fraud system. An order's responsibility should be maintaining information about the order and its status—not validating whether its fraudulent, which (if the fraud detector was worth its salt) would involve a lot of historical information about the ordering party, payment information, etc—none of which should bleed into the order system, and which is the kind of thing the fraud system assembles by listening to events from all over the place. In that scenario, were the fraud system's interface to change, there would likely be changes that have to cascade to every system that touches it (regardless of whether its developed with an actor model.)
I realize you probably wouldn't, in reality and given realistic requirements, architect the system entirely the way you've outlined before this. But given the constraints of a blog post, I think the OP can be forgiven the oversimplification of the example, and you (I think) should also be able to see that his implementation has merit in real-world scenarios.
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 :)