17

DDD + CQRS + EventSourcingを使用してアプリを作成することを検討していますが、ユーザー認証を行う方法を理解するのに問題があります。

ユーザーはクライアントに責任があるため、本質的に私のドメインの一部です。ASP.NET MVC 4を使用していて、SimpleMembershipを使用することを検討していました。ログインとユーザーの承認は同期操作であるため、結果整合性のあるアーキテクチャでこれにどのように対処しますか?

非正規化された認証テーブルを読み取り側に保持する独自の認証システムをロールする必要がありますか?これのセキュリティをどのように処理しますか?イベントストアとビューテーブルの両方にパスワードハッシュを保存することになりますか?

非常に多くの質問があります。誰かが光を当てることができれば、私は非常に感謝します:)

tldr; EventSource-applicationsでユーザー認証をどのように行いますか?

4

3 に答える 3

14

すべての「ドメイン」またはビジネスコンポーネントがDDDまたはCQRSを使用する必要があるわけではありません。ほとんどの場合、ユーザー情報は非常に雑然としているため、通常はDDDを使用できません。他のドメインは実際のユーザーに依存しません。通常、さまざまなドメインで共有される相関ID(UserId)があります。

システムでメッセージングを使用する場合、1つのオプションは、CQRSを使用せずにユーザーを登録および管理してから、コマンド(RegisterUser {UserId})を送信することです。これにより、ユーザー登録イベントが公開されます。他のドメインはこのイベントをリッスンして、必要なワークフローまたはARを開始できます。

于 2013-03-26T18:10:34.070 に答える
12

MVC CQRSアプリの場合、最初はすべてのユーザー関連情報をドメインに保持することから始めました。誰かが言及したように、RegisterUserCommandとUserRegisteredEventがありました。ドメインにユーザー情報を保存した後、そのイベントは公開され、読み取り側で取得されます。これにより、ユーザーが作成され、すべてのパスワードハッシュなどが生成されます。次に、読み取り側で認証を行います。コントローラーは、 「読み取りモデル認証サービス」を呼び出して、認証を行います。

その後、これを完全にリファクタリングすることになりました。コマンドを承認するためのセキュリティを組み込むには、ユーザー関連情報にアクセスする必要があることが判明しました。これは、コマンド処理側で行いました(このアプリは、「ファイアアンドフォーゲット」非同期コマンドをキューに送信する分散アプリです。反対側の自律リスナー)。次に、セキュリティコンポーネントは、ユーザープロファイルを取得するためにドメインへの参照を必要としました。これにより、参照に関する面倒な問題が発生しました。

ドメインや読み取りモデルに属するのではなく、より中心的なコンポーネントであると考えられる別のデータベースにユーザーセキュリティ関連のものを配置することにしました。ドメイン内のユーザープロファイル関連の情報と読み取りモデル(役職、TwitterアカウントのURLなど)は引き続き保持されますが、パスワードハッシュなどのセキュリティ関連の情報はすべて、この中央データベースに保存されます。その後、MVCとコマンドオーソライザーの両方が利用できるサービスでアクセスできます。

このリファクタリングでは、ユーザーの登録コマンドハンドラーからユーザーを登録するためにサービスを呼び出しただけなので、実際にはUIで何も変更する必要はありませんでした。そのようにする場合は、ユーザーサービス関連の操作をべき等にするためにここで注意する必要があります。これは、2つの情報ソース(ESとユーザーデータベース)を更新するため、副作用なしにコマンドを再試行できるようにするためです。

最後に、もちろん、この中心的なコンポーネントにメンバーシッププロバイダーを使用することもできますが、それには落とし穴があります。自分で書くことになりました-それはとても簡単です。その記事はこれにリンクしており、それを実装する方法の良い例を提供します。

于 2013-03-27T10:38:34.750 に答える
1

訪問者(サイトにアクセスしたばかり)、ユーザー(登録済み)、顧客(何かを購入した)などの個別のエンティティを作成することを検討する必要があります。データの冗長性が少し発生する場合でも、この方法でシステムを分割してみてください。ディスク容量は問題ではありませんが、システムのさまざまなコンポーネントを個別に変更する機能は通常、非常に重要です。

非正規化された認証テーブルは、スケーリングの目的で、認証読み取り側がパフォーマンスのボトルネックである場合にのみ作成されます。そうでない場合は、通常の第3正規形が最適です。

SimpleMembershipシナリオでは、SimpleMembershipによって作成されたすべてのテーブルを「ユーザー」集計のスナップショットとして表示できます。そして、はい、彼らはあなたのイベントストアのいくつかのデータを複製します。UserCreated、UserUpdated、UserAssignedToRoleなどのイベントが発生する可能性があります。

そして、そのメンバーシッププロバイダーの名前にだまされないでください。それはそれほど単純ではなく、通常はなくても簡単に生活できるものがたくさんあります(ドメインによって異なります)。だから、多分あなたはこのようなものを使うことができます:https ://gist.github.com/Kayli/fe73769f19fdff40c3a7

于 2013-03-27T00:57:04.397 に答える