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

Bookmarks

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

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.

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

Community comments

  • Another attempt to latch on to a popular term?

    by Eugene Tolmachev,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

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

BT