エージェント/アクターベースのコンカレント・デザインのデザイン・パターン

Question

最近、私はアクター/エージェント/シェアード・ナッシング・アーキテクチャーをサポートする代替言語になっています。 scala、clojureなど（clojureは共有状態もサポートしています）。

私が読んだドキュメントのほとんどは、イントロレベルに焦点を当てています。私が探しているのは、4人のギャングに沿ったより高度なドキュメントですが、代わりに何も共有していません。

なぜですか？デザイン思考の変化を突き詰めるのに役立ちます。簡単な例は簡単ですが、実際のJavaアプリケーション（シングルスレッド）では、複雑な関係を持つメンバーが1000人のオブジェクトグラフを持つことができます。しかし、エージェントベースの同時実行性開発では、大規模なシステムを設計する際に理解するための全く新しい考え方が導入されています。すなわち、エージェントの細分性 - あるエージェントが管理するべき状態の数 - パフォーマンスへの影響など、または共有状態オブジェクトグラフをエージェントベースのシステムにマッピングするための良いパターンです。ドメインモデルを設計するためのヒント技術に関する議論ではなく、設計でこの技術をどのように最善に活用するか（実世界の複雑な例は素晴らしいでしょう）。

Answer 1

私は同様の質問hereに尋ねましたが、これはいくつかの妥当な答えが役に立つかもしれません。私はあなたのことを慎重に見ています。私はまだ本当に私を助けた何かを見つけていないが、私は非常に積極的に探している。

私はマインドシフトが並行したアーキテクチャと言語にステップする最大の障壁だと思っています。それまでに開発者はMSスタイルのパラダイムを学びやすいでしょう。それが本当に主流になるためには、学校への道を見つけて、C＃とVBと一緒に教える必要があります。

2080 programmers questionに対する私の答えは「同時に」です。

Answer 2

デザインが パターンになるような実際の例はありませんが、始めるにはいくつかの場所があります。

最初は、あなたの頭がコンセプトの周りを適切に包み込まれています。あなたがこれを行う を助ける1つの本は、非常にアクセス可能な方法で並行処理指向プログラミング を説明しているErlang Guru Joe Armstrongによって書かれたMaking reliable distributed systems in the presence of software errors です。それは実際には博士号です。しかし、それがあなたを恐れることはありません。 最も一般的なテキストブックよりも読みやすく、楽しいです。

実際のシステムを見ると、実際には という言語についてあまりにも多くのことを学ばなければならないということを意味します。 Erlangの場合、documentation は、設計方法論と動作（デザインパターンライブラリ用のErlang speek）を提供します。 この設定で最も一般的に使用されるデザインパターンを示します。そして、これらの は、大規模システム、すなわち数百万行のコード（Javaのような他の言語の4~10の要素に匹敵する）と分散したマシンのマシンで実行される数百万の同時プロセスを構築するのに有効であることが証明されている。 実際のライブシステムの最近の例はFacebook Chatです。

他のフレームワークでは、私は恐れることができません。

Answer 3

「アクター」自体は、並行プログラミング（非同期メッセージキューとそれを処理するための実行コンテキスト）の統一パターンですが、エージェントベースシステムの側面または要素の指定を支援する多くの設計パターンがあります。最も一般的なものの多くは、ウィキペディアの記事Concurrency Patternsに掲載されています。いくつかのハイライトは：あなたはすでにそれに遭遇していない場合は

• Reactor Pattern
• Mediator Pattern
• Scheduler Pattern
• Observer Pattern

、Akkaはあなたに興味のある - それはJVM上で動作する「純粋な」イベント駆動型のアクターフレームワーク。