0

私たちは現在、(Web) アプリケーションを構築する新しい方法を調査しており、1 つの方法として頭に浮かぶのは CQRS です。これについては、まだいくつかの質問があります。

私の理解が正しければ、これはおそらく 2 つ以上のドメイン モデル、1 つのコア ドメイン モデル、および Web アプリケーション用の 1 つの読み取りモデルを持つことを意味します。

このコア ドメイン モデルは、webapp によって直接書き込まれるのではなく、別のサービスによって書き込まれます。NServiceBus を使用してパブリッシャー/ハンドラーを作成し、webapp がユーザーによる変更を公開できるようにすることを考えています。サブスクライバーはメッセージを処理し、コア ドメイン モデルと読み取りモデルを更新します。

私たちが達成したいこと:

ユーザー A は、10 個の新しいオブジェクト (本など) を作成します。

メッセージ サブスクライバーには処理するメッセージが大量にあるため、ドメイン モデルが更新されるまでに数分かかります。

ユーザー A がページを更新すると、作成したばかりの 10 冊の本が表示されます。

ユーザー B がページを更新するとき、実際にはこれらの項目を表示する必要はありません。

これらの 10 個の新しいオブジェクトをどこに保管するのが最適ですか?

このデータを読み取りモデルの「古い」データとマージする最良の方法は何ですか?

ユーザー B もこれらの新しいアイテムを見る必要があるとしましょう。その場合、このデータを保存する最善の方法は何でしょうか?

2 人の異なるユーザーが同時に同じ本を追加した場合の最善の対処法は何ですか? （本の説明を除いて、すべてのデータは同じです。それはまだ同じ本です:)

コア ドメイン モデルにまだ書き込まれておらず、一意の ID を持っていないこれら 10 個のオブジェクトの 1 つに対する更新をどのように処理できますか?

4

1 に答える 1

2

私の意見では、 CQRS には考慮すべきさまざまな側面があります。私が取り上げた重要なポイントは、ユーザーのアクション (コマンド -> モデルの書き込み) と情報の表示 (クエリ < - モデルの読み取り) の分離でした。その後、アプリケーションの要件に応じて、この分離に自然に適合する残りのアーキテクチャ パターンを適切に選択できます。CQRS は最上位のアーキテクチャを意図したものではないことに注意してください。適切な場合にのみ使用する必要があります。

あなたの質問から、あなたの研究はあまり進んでいない印象を受けるので、次のことをお勧めします。最初の CQRS ドキュメント、Rinat Abdullin のブログ、Jonathan Olivers ブログ (古いものを読む)、およびRinat の CQRS ガイド (このサイトはまだ読んでいませんが)。

CQRS のドキュメントを一読すれば、質問に自分で答えられることを保証します。

おそらく、使用したいパターン/テクノロジーを教えていただければ、より完全な回答を提供できます. しかし、最初の質問を開始するには、非常に簡単です。

これらの 10 個の新しいオブジェクトをどこに保管するのが最適ですか?

答えは、データの一部を書き込みモデルと読み取りモデルの両方に論理的に保存することです。物理的に、これは、選択したテクノロジと実装に応じて、同じデータ ストアまたは異なるデータ ストアに格納できます (たとえば、SQL サーバー データベースとキー値の非 SQL ソリューション)。

たとえば、イベント ソーシングの使用を選択した場合は、発生したイベントを書き込みモデルに保存します。読み取りモデルは、読み取りモデルのこのデータから画面を構成できるように、非正規化されたデータを格納します。しかし、それは私が見ているパターンに忠実です。読み取りモデルは、クエリサービスで正規化されたデータを格納するだけで、実際のデータベースに対して実際の SQL クエリを実行できます。

次のコメントを編集

私が現在取り組んでいるシステムは、イベントを使用しますが、メッセージングを使用しません。すべてが進行中です。したがって、コマンドが処理されます。イベントはすべて同じ作業単位内で発生し、処理されます。基本的に、コマンド ハンドラーは、適切なイベント ハンドラーがすべて完了するまで終了しません。

読み取りモデルにより集中的/複雑な更新がある場合は、アウトプロセスイベント ハンドラーを引き続き検討しています。しかし、この段階ではその必要はなく、物事をシンプルに保ちます。

結果整合性の全体的な側面は、パターンに付随するものです。「他の」ユーザーにとっては決して問題にはなりませんが、送信したばかりでページを更新したユーザーにとっては、送信したばかりの更新が表示されないため混乱していることがわかります。個人的には、更新を偽装するという考えは好きではありません。代わりに、確認ページにリダイレクトして、アプリケーションがメッセージを処理する時間を増やすオプションを好みます。

私が個人的にさらに探求したいのは、送信されたコマンドを追跡し、そこに関連するプロセス外イベント ハンドラーを追跡することです。まだ完了していないメッセージがあるページを更新しているユーザーは、不完全なメッセージについて通知を受けることができます。メッセージの処理が完了すると、クライアントに通知を「プッシュ」できます。ユーザーの気を散らしたり、邪魔になったりしないように、これらの通知は控えめにします。

于 2012-07-06T06:58:50.253 に答える