アクターモデルでMVCCを実現する方法

Question

私は、私のEmployeeエンティティをアクターとして表現しています。私は俳優としてもモデル化された2つのサービスを持っています。両方とも、メッセージを送信することによって受け取った従業員の俳優の状態を操作します。さて、両方のサービスが同じ俳優を処理しているとしましょう。今ではこれで結構です従業員の俳優は、2つのサービスAから以下の順に状態変化するメッセージを受け取ることは完全に可能であるとB

Employee <- |a1|a2|a3|b1|b2|b3|

。しかし、時にはそれはない

Employee <- |a1|b1|a2|b2|a3|b3|

たぶんa2がa1によって変更状態に依存していたが、我々は単一のスナップショット/バージョンで動作できるようにb1は、データベースと同様に

それを変更し、我々は取引を持っていますトランザクションのライフタイムを通じてデータの

必須のモデルでは、従業員オブジェクト全体をロックし、データベースの状態と同様の状態を更新します。

アクターは、アトミックな一連のメッセージとして処理される大量のメッセージを受信できる可能性がありますか？それとも、データ自体のモデリングに欠陥がありますか？

Answer 1

私はa1-a3とb1-b3が実際にどのようなものを表しているか分からないので、質問に正しく答えると仮定できます。私にはあなたのメッセージが細かすぎるようです。たとえば、おそらくa1-a3は各メッセージのデータの属性を1つだけ設定しようとしています。これはおそらくb1-b3にも当てはまります。

しかし、メッセージに焦点を当てるべきは、個々の属性を設定するのではなく、従業員の行動を引き起こすことです。したがって、あなた自身が提案するように、メッセージをビヘイビアとして設計します。ここで、a1-a3は単一の操作要求に崩壊します。これはしばしばコマンドパターンと呼ばれ、オブジェクト/俳優に何かを命じたり命令したりします。そうすることで、メッセージごとに正しいトランザクション境界が得られます。

上記の「オブジェクト/アクター」と言いました。あなたは、俳優だけでなく、あなたのオブジェクトデザインで同じアプローチを使用することができます/そうする必要があります。ドメインオブジェクト/アクターをダムデータホルダーとして扱うのではなく、意図を明らかにするインターフェースを考え、ドメインモデルにあなたのために何をしたいのかを伝えてください。

これは私の質問です。 HTH。

ヴォーン

Answer 2

どちらも、それはそれにメッセージを送信することにより を受けた従業員の俳優の状態を操作します。

定義によると、Actorはその状態またはその操作を他のActorと共有しません。すべての状態操作は、とメッセージ処理の境界内のトランザクションです。アクターはその意味で集合体を表します。メッセージは通常ドメインイベント/コマンドであり、範囲とユビキタス言語の一部を持っています。 DDDの推論は、アクターについて考えるときに多く役立ちます。

私がなってしまったものだ私の2セント

Sergiy <> <