BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Vaughn Vernon on the Actor Model and Domain-Driven Design

Vaughn Vernon on the Actor Model and Domain-Driven Design

This item in japanese

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

Share nothing
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.

Actor model
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.

Earlier this year, Eric Meijer, Carl Hewitt, inventor of the Actor Model, and Clemens Szyperski discussed and explained the actor model in a standing conversation close to a whiteboard.

Rate this Article

Adoption
Style

BT