私はしばらくの間 Scala に手を出しており、遠くから Akka を研究してきましたが、ついに本格的に始めようとしています。FSM トレイトが私の契約を結びました。私が懸念しているのは、データが不適切に共有される方法を思いついた可能性があることと、Akka のベスト プラクティスに一致するようにイベント処理ループを誤って考えた可能性があることです。
私の問題では、着信タスク要求を、有限状態マシンでもある適切なアクターに一致させる中央コーディネーターがいます。私は当初、onTransition が状態名だけでなく状態データも提供すると想定していました。
従来のデータのカプセル化が、そのデータをリスナーに公開しない理由になると思います。しかし、私にとっては、他の人がそのデータを見るために 2 つの用途があります。
状態データには基礎となるドメイン オブジェクトが含まれており、そのプロパティを使用して、要件が与えられたジョブを処理するのに最適な候補となるアクターを決定します。ジョブの要件は動的であるため、ワーカー アクターの個別のコレクションを持つことをためらっています (ただし、なぜ一時停止する必要があるのかはわかりません)。
他の前提条件を満たすすべての個別のアクターにクエリを実行し、すべての応答に参加するというアイデアは、非効率的であるか、少なくとも Akka にとって慣用的ではないように感じます。また、UI に現在の状態を表示する必要があり、同じイベント キューを使用して状態を表示する必要がある理由がわかりません。
とにかく、FSM にエージェントを更新させることを検討していましたが、それ自体がアクターであるため、その間接的な層が私に何をもたらすのかわかりません。イベントのシーケンスについての推論がはるかに難しくなる可能性があります。
Fowler の Event Collaboration は、状態データを明示的に送信することを私に指摘していますが、状態データを自動的に更新するすべての遷移に対してこれを行う簡単な方法を望んでいました。
また、イベント カスケードの順序付けと、それを制御する必要があるかどうかについて頭を悩ませています。すべての着信外部イベントが 1 つのアクターを経由する場合でも、内部で生成されたすべてのイベントを他のすべてのアクターに対して処理してから、次の外部イベントを処理する必要があります。セントラルコーディネーターに使ってもらいたいと考えていました!! 応答を待つ必要がありますが、イベント チェーンのどこかで感嘆符を誤って 1 つ削除すると、その保証が失われるのではないかと心配しています。
この問題に対して私が検討している解決策には、共有されるすべての「内部」アクターに対して単一のスレッド化されたディスパッチャー (おそらくワークスティーリングを使用) を使用して、内部イベントに高い優先度が与えられるように優先イベントを使用することが含まれます。
私がやろうとしていることに関連するベストプラクティスはありますか、それとも間違ったことをしようとしています:)?