BT

Your opinion matters! Please fill in the InfoQ Survey!

Vaughn Vernon on the Actor Model and Domain-Driven Design

| by Jan Stenberg Follow 10 Followers on Jun 16, 2013. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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 Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Another attempt to latch on to a popular term? by Eugene Tolmachev

I'm using a piece of tech that implements Actor pattern in conjunction with DDD myself, but this whole overview makes me cringe:
- 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".

Re: Another attempt to latch on to a popular term? by Lucian Naie

To my knowledge, akka or ms orleans implement an actor model.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT