最新のマルチコアマシンは、並行処理技術が秘める大きな可能性を我々 にもたらすが、それをうまく活用していくためには、並行処理に適し たプログラミングモデルを用いるべきであり、 いわゆるアクターモデル がそれを達成するための道具を多数与えてくれる―「ドメイン駆動設計の実装 」の著者であるVaughn Vernon氏は、今 年ロンドンで開催され た「DDD Exchange Day」でこのように述べた。
アクターモデルが今まであまり人気とならなかった理由の一つは、 それに適したマシンを利用できるチャンスを我々が本当には得ていなかったためではないだろうか。 今や、我々のマシンには多くのコアが備わっており、状況は変化している。処理規模を拡大し、並列性を利用していくために 我々が進んでいる道は、おそらくいままでとは異なったものとなるにちがいない。 それゆえ、我々はアクターモデルを詳しく調べておくべきである、とVaughn氏は考えている。
直接的な非同期メッセージング
アクターは、他のアクターにメッセージを送るが、メッセージを非同期的に送信した後も、 その機能を継続することができる。 必要なことはただひとつ、受信側アクターのアドレスだけである。 このアドレスは、送信側がアクターを作成した際に得たものか、 あるいは、受信したメッセージから得たものであるかのどちらかである。
ロックの必要がない並行性
ロックを避けるため、アクターモデルはキューイング機構を採用している。 キューは、アクターが一度に一つのメッセージだけを扱うことを意味し、 メッセージが到着する順序は保証しない。
非共有
アクターは、このモデルにおける演算の根本的な単位であり、 個々のアクターは独立しているため、自身の状態を完全にカプセル化していて、お互いに状態を共有することはない。 また、アクターはイミュータブル(変更／破壊不能)な方法だけを使ってデータを返す。
"Future"と"Promise"
問い合わせが非同期に配信されたなら、回答は未来("future")のいずれかの時点で非同期的に戻される。 "Future"とは、メッセージが送信されたら即座に返され、後ほど答えを返すことの約束("promise")を表現した概念である。 （参考：wikipedia「future」）
アクターモデルと、ドメイン駆動設計
アクターモデルは、ドメイン駆動設計(DDD)との相性がよい。 DDDでは、メッセージの形で表現されるユビキタス言語の概念と、 アクターとして表現されるアグリゲートという概念を使用する。 メッセージはアグリゲートへ直接送信できる。アグリゲートは、ビジネスルールを持ち、エンティティを永続化する実体である。 また、このことは「１回のトランザクションでは、ただ１つのアグリゲートだけが状態を更新する」という原則に自然に適合するものとなる。 こうした設計を適用すれば、現在の典型的なイベント駆動アーキテクチャーがもつ複雑性が減少でき、 実装が単純化されるのではないか、とVaughn 氏は考えている。
アクターモデル
アクターモデルでは、各々のオブジェクトは、メイルボックスと振る舞いを持ったアクターであり、 メールボックスを通じてアクター間でメッセージを交わす。すべてのメッセージ通信は非同期に実行され、 アクター間の状態の共有はない。
今年のはじめ、アクターモデルの発明者のEric Meijer氏、 Carl Hewitt氏、そして Clemens Szyperski氏が、ホワイトボードのそばの立ち話で、アクターモデルについての 議論と説明を行った。