4

ベースライン情報： ログインに外部OAuthプロバイダーを使用しています。ユーザーが外部OAuthにログインすると、システムに入ることができます。ただし、このユーザーはまだ私のシステムに存在していない可能性があります。これは実際にはテクノロジーの問題ではありませんが、私はJOliverEventStoreをその価値のために使用しています。

論理：

  1. 新規ユーザー向けのGUIDは提供されていません。メールアドレスを持っています。
  2. コマンドを送信する前に読み取りモデルを確認します。ユーザーの電子メールが存在する場合は、IDを使用してLoginコマンドを発行し、存在しない場合は、生成されたIDを使用してCreateUserコマンドを発行します。私の問題は、新しいユーザーの場合です。
  3. 新しいIDでイベントストアに保存が行われます。

問題： ブラウザーの更新または読み取りモデルとの整合性が達成される前に発生するその他の異常のために、読み取りモデルが更新される前に2つの作成コマンドが何らかの形で発行されたと想定します。それは大丈夫ですそれは私の問題ではありません。

何が起こるか： 新しいIDはGuidコームであるため、イベントストアがこれらの2つのCreateUserコマンドが同じユーザーを表していることを知る可能性はありません。読み取りモデルに到達するまでに、読み取りモデルは（同じ電子メールを持っているため）認識し、2つのレコードをマージするか、その他の補正アクションを実行できます。しかし、現在、私の読み取りモデルは、これらが2つの別個のエンティティであるとまだ考えているイベントストアと同期していません。

おそらくそれは問題ではありません：

  1. イベントを再生すると、読み取りモデルにも同じ効果があるため、問題ありません。
  2. 両方のコマンドは重複する「作成」コマンドであるため、同じ情報が含まれている必要があります。したがって、イベントストアで何かを失っているわけではありません。

誰かが同様の問題をどのように処理したかを明らかにすることができますか？何らかの補正アクションを実行する必要がある場合、読み取りモデルサービスは、重複エントリがあることに気付いたときに、ある種の補正コマンドを発行しますか？私が検討していないより単純な方法論はありますか？

4

1 に答える 1

7

あなたは私が適切な可能な解決策と考えるものに非常に近いです。要約すると、シナリオは次のようになります。

  • OAuth認証を実行します。
  • 読み取りモデルを使用して、電子メールアドレスに基づいて、定期的な訪問者と新しい訪問者のどちらかを決定します。
  • 新規訪問者の場合は、RegisterNewVisitorコマンドメッセージを送信して、イベントストアで処理および保存します。
  • 同じ電子メールアドレスに対して、2つのRegisterNewVisitorメッセージが発生し、それぞれにシステムが電子メールアドレスに関連付けられたキーであると見なすものが含まれているという並行性が発生していると仮定します。これらのキー（GUID）は異なります。
  • 読み取りモデルでこの重複するキーの問題を検出し、両方の読み取りモデルレコードを1つのレコードにマージします。

ここで、読み取りモデルのレコードをマージする代わりに、ResolveDuplicateVisitorEmailAddress {Key1、Key2}をドメインモデルに送信して、この問題を解決するためにドメインモデル（成文化された形式のビジネス決定）に任せてみませんか。この種の問題に対処するための専用の読み取りモデルを用意することもできます。他の読み取りモデルは、一種のDuplicateVisitorEmailAddressResolvedイベントを取得し、それを適切なレコードに投影します。

警告の言葉：あなたは技術的な質問をしました、そして私はあなたに技術的で可能な解決策を与えました。一般に、これに投資する価値があるというビジネス指標がない限り、この手法を適用しません（ユーザーが初めて同時にログインする頻度はどれくらいですか？この方法で解決することは、根本的な原因を無視する方法にすぎません。 （Flakey OAuth、新規訪問者プロセスの登録なしなど））。この問題には他にも技術的な解決策がありますが、私はあなたがすでに実施しているものに最も近いものを提供したいと思いました。それらは、新しい訪問者を順番に登録することから、まだ読み取りモデルにない訪問者のメモリ内予測を維持することまで多岐にわたります。

于 2012-06-30T11:17:22.760 に答える