Building a Reactive Process Manager, Twice

On February 24, 2015, I delivered a presentation by this title to a meetup in the Netherlands. The group name is DomCode, and we had a packed house of more than 80 attendees. This topic not only drew a lot of attendees but held their rapt attention throughout more than an hour.

The first half of the presentation introduces you to Actor Model with Scala and Akka, and also includes a bit of discussion on using Actor Model with C# and Dotsero. Dotsero is my Open Source toolkit that supports using Actor Model on the .NET Platform.

The second half of the presentation explains what a Process Manager is, and how to buildĀ one. I walk through both Scala and Akka and C# and Dotsero implementations.

Now you can watch the recorded video.

The Process Manager is one of the patterns I discuss in my upcoming book, Reactive Enterprise with Actor Model.


  1. Apologies to be off topic, but I was wondering what happened to the Number9 approach. I cannot find the blogposts anymore. Has this approach been obsoleted by any kind of progress somewhere else e.g. within Akka’s persistence?
    Thank you, Dan

    • After discussions with Roland Kuhn, the Akka team lead, I have decided to pull the Number 9 work out and not include it in my book “Reactive Enterprise with Actor Model”. Roland’s argument was that what I was doing is semantically the same as is done in Akka Persistence with PersistentActor and AtLeastOnceDelivery. Although Number 9 took a different approach, it was susceptible to database contention, which in the end would be bad for thread usage. So have made the decision to support only the Akka Persistence way.

  2. Hi,
    I have couple of questions regarding use of actor model in DDD paradigm.
    1) In your presentation you mentioned, while discussing about Number9 toolkit, that you wanted to directly send message to Vector of ActorAggregates in case of a domain event generated from another Actor/Entity. My question regarding this comment is that if we are following publish-subscribe model than why subscribers should be known to publisher? Also what ever happens in response to that Domain Event why should it matters to the creator of the event? (Is it required because we need to directly send the message into the mailbox of other known actors. If that is the case then don’t you think we are adding more responsibility to ActorAggregate).

    2) I read your book Implementing Domain Driven Design and I learned a lot from that. In fact I tried to apply different approaches suggested in the book in one of my recent project. In that project I used to Spring Integration not only orchestrate publish-subscribe model for domain events but also to integrate with external services. It helped me applying different enterprise integration patterns and also in creating a hexagonal/onion architecture. After seeing the presentation I was wondering why you want to use AKKA/Actor model for achieving the same thing provided by tools like spring integration or apache camel.
    I know you have a good answer for this question but I just want to clarify my understanding.

    Thanks, Noor

    • Hi Noor,

      First, the Actor model is focused more on point-to-point communications. The idea behind the multi-send API is that you may want to both broadcast a message and send it directly to a known actor. It doesn’t have to be used, but it can work out well if you need it.

      Secondly, there are several reasons why Actor model makes sense for DDD. Actor model allows for very broad scalability with performance. The message sending of Actor model is a nice way to model a Ubiquitous Language. The actor makes a natural aggregate. As Alan Kay said, “the Actor model retained more of what I thought were the good features of the object idea.” Actor model puts the correct emphasis on modeling the message-based communications between objects rather than the internals of the objects, and it’s the messages that reflect the essense of the Ubiquitous Language.

      I hope this helps.