7

I’m currently learning about the Actor design pattern, or model, and it seems quite interesting. However, I’m struggling to find any decent real-world examples of how, or where, this model could be applied (other than the basic examples of a simple bank account with a balance, or Enemy coordinates for a game, etc).

As part of my research I came across a sample e-commerce microservice application (eShopOnDapr) where the Order was an Actor. Would this be a real-world example of where the Actor model could be used?

Can this, or should this, design pattern be used with microservices? Using the example above, the Ordering service only deals with an Order, but not products or customers, etc. It makes sense to me that an Order might be an Actor, but is it better to just build the service using some other technique, like using CQRS, or even just basic state management (create an instance of an Order and record it’s state each time it’s updated)

As you can see I still have a fair bit of learning to do is this area of design patterns but it would great if anyone could point me to some good doco, or YouTube clips, that explains these things with some good real-world examples.

Arnold Schrijver
  • 3,588
  • 3
  • 36
  • 65
Dazfl
  • 627
  • 8
  • 23

3 Answers3

6

If your app is relatively straightforward, and it could be e.g. a synchronous CRUD REST app, then actor model may be overkill.

For larger more complex domains, with more moving parts the Actor Model may ease how you think about your app and are able to break it down into constituent parts. There are plenty of architectural considerations and options to take into account, and they largely depend on your specific use cases and non-functional requirements (NFR's).

As @levi-ramsey says in his answer CQRS might be used in addition to actors, but is optional. It is an independent choice to add it. So too are Event Sourcing (ES) and e.g. Domain-Driven Design (DDD).

Some NFR's where actor model is helpful are distribution (location-transparency of actors) and resiliency (delegate to child actors, and "just let them crash" where a supervisor may restart or escalate errors). Actor model may abstract away a lot of network plumbing which is a boon in microservices architectures.

Depending on domain complexity, business logic, need for modularity/extensibility, scalability etc. it makes more sense to combine various architectural practices, such as Actors/DDD/CQRS/ES and hexagonal architecture. But only if your app warrants it.. they each have their pros and cons (like 'eventual consistency' in microservices and event sourcing).

The above combination is found in Distributed DDD (DDDD), also called Reactive DDD. There's some good videos by Vaughn Vernon to be found here e.g. Using the Actor Model with Domain-Driven Design (DDD) in Reactive Systems (he turns domain aggregates into actors), and also Alexey Zimarev in DDD, Event Sourcing and Actors (he places the actor logic in the application layer).

You'll find lots Akka-related material. They have good documentation material. Personally I find proto.actor interesting, created by one of the Akka founders, and with Alexey part of the team.

In terms of design patterns this article Meet the Top Akka.NET Design Patterns is a good start. The Akka documentation has a section on Interaction Patterns. Though I haven't read it, I think Applied Akka Patterns book by O'Reilly is quite good.

In terms of example code the Github actor-model topic may lead to some great projects to learn from, and also e.g. the Proto Actor project has a big list of Golang examples or DotNet examples to apply from, and a Bootcamp course.

Arnold Schrijver
  • 3,588
  • 3
  • 36
  • 65
1

The actor model has a high degree of mechanical sympathy with microservices, though it tends to be more applicable to thinking about the implementation of services.

It likewise is not exclusive to CQRS.

If you're looking for a good example of the use of the actor model along with event-sourcing and CQRS in a microservice is Lightbend's Akka Platform Guide.

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
  • Thanks for the link @levi-ramsey. This is interesting. What I'm struggling with is trying to determine when to use, and not to use, the Actor pattern. In the shopping cart example, the cart is an Actor, but what about Products, for example? Could a product be an actor? Or a customer? – Dazfl Feb 16 '21 at 05:31
  • 2
    In general anything that has state which can change is well-modeled as an actor (pretty much any domain object can be). Whether it's a good idea to model product as an actor in a particular service depends on the service. In a cart service, where probably don't want an item description etc. changing in the cart, it might not make sense, but in a catalog service handling commands to update product descriptions, prices, etc. an actor could be a really great fit (I personally would say it is, but I've drunk the actor model koolaid :) ). – Levi Ramsey Feb 16 '21 at 11:53
0

I'm going to wake this one back up because I wound up here because I was reviewing the exact content that @dazfl was and was trying to figure out if I was just being a purist or if that use of actors was inappropriate. You know, like using a pair of pliers to drive a nail. It works, but should you do it?

I got into the actor model via the Reliable Actors framework in Azure Service Fabric. I always attempt to understand exactly what the originators of an idea had in mind before applying it myself. I have read Carl Hewitt's doctoral dissertation followed by the much more robust dissertation of one of his grad students from the mid-80s.

One of the things I have concluded is that a proper actor application will have lots of small actors with a limited number of message types. It is really critical to view actors as receivers of messages rather than called objects. Without this shift in mindset an actor implementation winds up looking like any other form of distributed application. And we all know how tricky those are to do well.

The eStoreOnDapr order service does not make good use of the actor model. It works, but actors don't bring anything to the party. I think the writers are using the turn-based model to simplify some things which is fine. But only scratches the surface of what the model brings to the party and is not worth the learning curve for that use case.

Mark Eisenberg
  • 9
  • 1