MVC CQRSアプリの場合、最初はすべてのユーザー関連情報をドメインに保持することから始めました。誰かが言及したように、RegisterUserCommandとUserRegisteredEventがありました。ドメインにユーザー情報を保存した後、そのイベントは公開され、読み取り側で取得されます。これにより、ユーザーが作成され、すべてのパスワードハッシュなどが生成されます。次に、読み取り側で認証を行います。コントローラーは、 「読み取りモデル認証サービス」を呼び出して、認証を行います。
その後、これを完全にリファクタリングすることになりました。コマンドを承認するためのセキュリティを組み込むには、ユーザー関連情報にアクセスする必要があることが判明しました。これは、コマンド処理側で行いました(このアプリは、「ファイアアンドフォーゲット」非同期コマンドをキューに送信する分散アプリです。反対側の自律リスナー)。次に、セキュリティコンポーネントは、ユーザープロファイルを取得するためにドメインへの参照を必要としました。これにより、参照に関する面倒な問題が発生しました。
ドメインや読み取りモデルに属するのではなく、より中心的なコンポーネントであると考えられる別のデータベースにユーザーセキュリティ関連のものを配置することにしました。ドメイン内のユーザープロファイル関連の情報と読み取りモデル(役職、TwitterアカウントのURLなど)は引き続き保持されますが、パスワードハッシュなどのセキュリティ関連の情報はすべて、この中央データベースに保存されます。その後、MVCとコマンドオーソライザーの両方が利用できるサービスでアクセスできます。
このリファクタリングでは、ユーザーの登録コマンドハンドラーからユーザーを登録するためにサービスを呼び出しただけなので、実際にはUIで何も変更する必要はありませんでした。そのようにする場合は、ユーザーサービス関連の操作をべき等にするためにここで注意する必要があります。これは、2つの情報ソース(ESとユーザーデータベース)を更新するため、副作用なしにコマンドを再試行できるようにするためです。
最後に、もちろん、この中心的なコンポーネントにメンバーシッププロバイダーを使用することもできますが、それには落とし穴があります。自分で書くことになりました-それはとても簡単です。その記事はこれにリンクしており、それを実装する方法の良い例を提供します。