What's up with the Actor Model?
From our discussion, it's clear that we have some entities that act on receipt of some messages, or let's say requests. We call them Actors. To solve some domain-specific problems, we might want to have more than one Actor. Think of a basic scenario of e-commerce checkout flow. There's more than one area of concern. The following diagram represents the basic intended flow:
By taking a look at the diagram, it's clear that we have few entities, and these entities are going to take care of specific concerns. We have named these entities based on their area of concern:
- CheckoutActor might have the responsibility to fetch details from the cart and show the respective information.
- Additionally, you might want to apply some coupon code or offer. Our system has to validate that coupon or offer code and based on that we might want to modify order details. For this particular process, we have HandleOffersActor.
- ShippingActor has the responsibility of fetching user-specific...
