Are Actor Model objects the same as domain Entities in an eCommerce system?

Question

Trying to understand Actor Model design.

So in general, actor objects should have behaviour, responsibilities, and state that need to be managed and coordinated with other parts of the system. They should also be designed to handle concurrent access and messaging between different actors.

So that sounds like domain Entities and Aggregates (in DDD) to me.

So if in an eCommerce application users are, logged-in, browsing and adding products to their basket. In this case there are at least 3 actors User, Basket, Product, Catalog etc

• each User logged-in is an actor
• each User actor will have a Basket actor ref
• there is one Catalog actor shared amongst all users
• there will be one instance of Product actor for each unique product in stock
  • so if only books are sold but for example only three specific titles are offered
  • and there are ten copies per title
  • then there are only three Product actors in memory (one for each title) with inventory-level of 10

Does that all sound right?

• Can these be implemented as Actors
  • Entities
  • Aggregates
  • Stateful/Stateless Services
  • Repositories
  • Factories
  • Events

Answer 1

Yes, DDD aligns extremely well with actors. In fact, rather than reading my answer I'd recommend taking Lightbend's (free) Reactive Architecture course. Because that's going to be the best practices and it's been a while since I've taken it.

While that course not technology specific, if you complete the course it's generally fairly self-evident how you would implement an e-commerce DDD design in Actors. There are several case studies that are directly applicable to an e-commerce design. You should take all of the course, but modules 2 and 3 are the ones most directly applicable here.

Q1: Does that all sound right? [e.g.User, Basket, Catalog, Product all represented by actors]

This is broad, maybe too broad for StackOverflow, but mostly. Like all DDD, it really comes down to the business and the way they see their functionality.

From the perspective of an ecommerce application, are a user and a basket really two entirely independent things (e.g. two different aggregate roots)? Or is a basket just an entity? Or even a value object? It will depend on how the business defines things. I suspect that in a mature e-commerce system basket will be a separate aggregate root, but it does depend on the business. The same question could be asked of Product and Catalog. Are they truly completely independent?

These may seem like obscure details, but they are very relevant to your choice about whether each of these are actors. Actors are boundaries. They are, by definition, only connected with other things via asynchronous messages. So if product and catalog are tightly coupled then implementing them as two separate Actors can be very problematic. (The newbie inclination is to make your actors too finely grained.) Perhaps you have a Catalog actor that has a collection of Products as its state [e.g. entities]? Without talking to the business about the business language/business rules, I cannot tell you.

Can these be implemented as Actors? [Entities, Aggregates, Stateful/Stateless Services, Repositories, Factories, Events]

Well, it's software, you can do anything with anything.

But, generally [and this is my personal opinion, most of these are debateable]:

• Aggregates make excellent Actors
• Entities sometimes work as child actors, but sometimes that's overkill
• Stateful/Stateless Services can make sense as actors, although there are usually better abstractions that may use actors behind the scenes
• Repositories probably would make excellent actors, although I will admit that I usually don't talk about this DDD pattern as much as use some of the others. A lot of actor concepts probably align very well here, but I'd have to go read the blue book again to validate my thinking.
• Factories are similar. I feel like this, by definition, would make for a great actor, but I'd want to double check the blue book.
• Events typically don't make sense as actors. They generally get implemented as case classes, assuming you are in Scala, and you then pass around the events as message between the actors.