I have not seen you covering Distributed DDD in the book. Do you think the actor model helps to distribute the aggregate roots (many instances) in a single node and later to multiple nodes to increase scalability? Or do you suggest an infrastructure component like NServiceBus to distribute the domain?

I looked at the Actor model, and see that there is no guarantee of delivery of messages. There is no retry of the commands. There is no persistence of the messages concept as in NServiceBus.

Let us know your thoughts on distribution.

Hey,

DDDD (Distributed Domain-Driven Design) is covered in part 2 of the book where communicate between bounded contexts using asynchronous domain events and commands. We refer to it as strategic DDD in the book, but strategic DDD and Distributed DDD are basically the same thing.

For the past 2 years I've been a Scala developer, heavily using the actor model (before that I was C# .NET) with Akka.

I'm a huge fan of the actor model, but it has it sweet spots and many contexts where it's best to be avoided. You can definitely use the actor model with DDD. Vaughn Vernon has been posting some great examples for a few years now https://vaughnvernon.co/?p=770. I'm looking forward to his new book Reactive Enterprise which will cover this in more detail.

You're right, the actor model does not include the concept of distribution and fault-tolerance, but you can easily add that. See Akka persistence for example: http://doc.akka.io/docs/akka/snapsho...rsistence.html.

Me too. I have Vaughn Vernon's other books. He is suggesting to use AKKA to take the DDD to another level. When it comes to distribution, by considering the operational aspect Martin Flower discourages to distribute the domain.

Coming back to the actors, should I consider two actors types Auction and BidOnAuction (Chapter 21) if I do the same with actor model and create many instances in the code of both in the ActorSystem to scale?

I tried AKKA.NET recently. I created 1000 products and a few categories. To send a message from a Product to a Category, I have to find the category from the system using query (have all the actorrefs in a IEnumerable) and have to Tell the Category to do something. I see the advantage of caching and threading issues (concurrency) when the aggregates are distributed.

The big difference I feel is that in a distributed DDD, I will be first reading from repository, bring to life and acting on it. In the case of actor system I act on an actor that exists in memory. Is that correct?

I wouldn't expect BidOnAuction to be an actor. BidOnAuction is a behaviour of the domain. I'd expect that would be a message or command sent by an actor.

Distributing the domain model adds a lot of complexity, so it's also something that I would be looking to avoid. Depending on the domain, though, it might provide enough of a benefit to be worthwhile.

Actor systems are designed that so you can have millions of actors in memory at any one time, but I'm not sure you would want to have an actor for every one of your entities in memory all at the same time. Rather you would probably create an actor and have it destroyed at the end of the transaction.

So, I believe the benefit comes when thousands of clients hit an app (like a REST end point) made with actor system, so it can spawn millions of actors to increase the scalability. I believe with .NET it will be limited to how many threads it can handle so thousands of clients hitting the application (not developed with the actor system) will be blocked. Does that make sense?