Vaughn Vernon on the Actor Model and Domain-Driven Design
To take advantage of the great concurrency opportunities the new multi-core machines gives us we should use a programming model that helps us achieve this, and the Actor Model gives us a number of tools for doing that, Vaughn Vernon, author of Implementing Domain-Driven Design, stated at this year’s DDD Exchange Day in London.
One reason the Actor model has not been so popular may be that we really haven’t had the opportunities with the machinery available. Now, with a lot of cores in our machines, that has changed and the way we are going to scale and use concurrency is probably going to be different than before. Vaughn therefore thinks we should look into the Actor model which gives us a number of tools to achieve this.
Direct Asynchronous Messaging
Actors sends messages to other actors but can continue to function since messages are sent asynchronously. The only thing needed is the receiver’s address which the sender gets either from creating an actor or from a received message.
Lock Free Concurrency
To avoid locking the Actor model emphasizes queuing which means an actor deals with only one message at a time, but there is no guarantee about the order of messages received
Actors are the primary unit of computation and each individual actor is therefore completely encapsulating its state, no state is shared. An actor may only return data in an immutable way.
Futures and promises
As a query is delivered asynchronously, the answer will be returned asynchronously sometime in the future. A Future is returned immediately when a message is sent and represents a promise to return an answer.
Actor model and Doman-Driven Design
The Actor model is well-suited for Domain-Driven Design; with messages representing concepts in the ubiquitous language and using aggregates as actors, a message can directly be sent to the aggregate where business rules are applied and entities persisted. This also naturally applies the principle that only one aggregate should be modified in one transaction. Vaughn thinks this will simplify the implementation by removing some of the complexity found in today’s typical event-driven architecture.
In the Actor model, each object is an actor with a mailbox and behaviour, with messages exchanged between actors through the mailboxes. All communication is performed asynchronously and without shared state between the actors.
Another attempt to latch on to a popular term?
- Aggregates are domain concept, and including any supporting tech in its interface is counter to DDD objective. It's a perfect candidate for a transaction scope, however.
- Realistically, "Share nothing" is neither achieved, nor desired unless dealing with side-effects free computation - transaction implies read/write with a storage, which is a side-effect.
- Consequently, if anyone knows of a practical lock-free implementation or a pattern, it would make for a great read.
There's no need for theoretical tie-ins, however there are practical aspects of DDD that can be addressed with Actor model nicely. Focusing on that, a CQRS example in any given language/runtime can provide better value than throwing out statements like "using aggregates as actors".
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014