8

CQRS (Command-Query Responsibility Segregation) アーキテクチャ パターンを使用して、StackOverflow のようなサイトを構築できますか? 私は CQRS と DDD (ドメイン駆動設計) に比較的慣れていないので、パターンを調査し、パターンに慣れているサイトをモデル化しようとしています。CQRS が StackOverflow のようなサイトの多くの側面で役立つことはわかりますが、可能かどうかわからない領域がいくつかあります (少なくとも、すぐにはわかりません)。具体的には：

  • 質問する 質問 を作成すると、すぐに表示され、編集できます。CQRS で「AskQuestion」などのコマンドを発行すると、「QuestionAsked」というイベントが作成されます。最終的に、質問は非正規化データ ストアにプッシュされます。しかし、SO の経験はすぐにわかります。これはCQRSで可能ですか？
  • 投票 私の投票はすぐに反映されます。CQRS では、これらのコマンド/イベントが最終的にイベント バスを介して読み取りストアに移動することを想像します。しかし、SOはすぐに情報を提供してくれます。

私の懸念は、SO が提供する即時フィードバックの概念に関するものです。CQRS はこれを提供できますか? もしそうなら、これはどのように行われますか？これを処理する方法を示す良い例はありますか?

それが役立つ場合、私の環境は VS2010/C#/SQL2008R2 ですが、SQLite などの他のオプションも受け入れています。また、NCQRS と LOKAD のフレームワーク、および Mark Nijhof のサンプルも検討しており、Greg Young のサンプルをダウンロードする予定です。 . CQRS サンプルについては、他にあまり見つかりませんでした。

ありがとう！

4

4 に答える 4

8

2つの質問を見てみましょう...

質問する 質問を作成すると、すぐに表示され、編集できます。CQRS で「AskQuestion」などのコマンドを発行すると、「QuestionAsked」というイベントが作成されます。最終的に、質問は非正規化データ ストアにプッシュされます。しかし、SO の経験はすぐにわかります。これはCQRSで可能ですか？

これは簡単に実現できます。すべてのユーザーが質問をすぐに確認する必要がありますか?それとも質問者だけが確認する必要がありますか? 全員に表示されるまでに 1 ～ 2 秒かかるとしたら、違いはありますか? ほとんどの場合、結果整合性システムでは、リクエストを送信するユーザーと他のすべてのユーザーに違いがあります。

投票 私の投票はすぐに反映されます。CQRS では、これらのコマンド/イベントが最終的にイベント バスを介して読み取りストアに移動することを想像します。しかし、SOはすぐに情報を提供してくれます。

SOはすぐにそれを与えますか？別の例、Facebook を試してみましょう。何かに「いいね」をクリックすると、すぐに「いいね」に表示されますか? 親指を立てるなどの UI トリックは、そのような気分にさせます。別の例、アマゾン。「カートに入れる」をクリックすると、すぐにカートに入りますか? 「カートに追加されました」や「高評価」などの視覚的表現は、ユーザーとしてのあなたをやり遂げたような気分にさせます。

最終的に一貫性のあるシステムを完全に一貫性のあるシステムのように感じさせることができる、このような多くのトリックがあります。

補足として、多くの人は、これらの種類のことはスケーラビリティのために行われていると考えています (これは場合によってはそうです)。多くの場合、信頼性のために行われています。問題は、XYZ がダウンしている場合に発生します。奇妙なランダム化されたローカル障害が必要ですか、それとも広範囲にわたる停止の危険を冒したいですか。ここで見られる最良の例の 1 つは、kindle の購入を Amazon でチェックアウトすることです。他の人は 3 ～ 5 秒かかるのに、Amazon が 100 ミリ秒ほどでクレジット カードを処理できるのは奇妙です :) クレジット カード処理システムがダウンした場合はどうなりますか?

于 2015-08-06T18:08:59.527 に答える
6

あなたが実際に話しているのは、CQRSと同時に頻繁に話される「結果整合性」ですが、どちらの手法も独立して使用できます。

最も簡単な方法は、UI が使用しているモデルをすぐに更新し、これを使用してユーザーに質問を表示し、さらに操作できるようにすることです。他のユーザーが更新を確認できるようにするためのさまざまな作業は、UI をブロックすることなく続行できます。これが機能するには、コマンドを送信する前にほぼ確実に成功するようにコマンドを検証する必要があります (実行中にコマンドが失敗した場合は、UI モデルに何らかのコールバックを組み込むなど、状況を処理する必要があります)。 .

また、通常、この種のことの「最終性」は非常に迅速であるため、他のユーザーにさえ、とにかくすべてがすぐに表示されることを覚えておく価値があります.

于 2010-09-06T12:45:40.427 に答える
3

質問をすると、UI でデータを「偽装」できます。ユーザー (あなた) にはすぐに更新されたように見えますが、他のユーザーがあなたの質問を見るまでには時間がかかります。投票を処理するには、同じことを行う必要があります。

すぐにフィードバックが必要な場合は、他の解決策を検討してください。ただし、CQRS ソリューションですぐにフィードバックを提供するために実行できるいくつかのトリックがあります。たとえば、ユーザー名が一意であることを検証する必要がある場合は、読み取りデータベースにクエリを実行して、ユーザー名が存在するかどうかを確認できます。そうでない場合は、使用できます。ただし、その間に他のユーザーが同じユーザー名を選択した場合、コマンド側で競合が発生します。ドメイン モデルでこれを処理する必要があります。たとえば、生成されたユーザー名をユーザーに与えて、電子メールで送信する必要があります。彼は後でそれを別のものに変更できます。

于 2010-09-04T23:35:58.457 に答える
1

偽物またはトリックによって、イベントを「保留中のイベント」と考えることができます。これは、コミット/パブリッシュ フェーズで成功する可能性が高く、失敗する可能性があるものです。コミットのための最初の送信の前に、クライアント側で実行する検証が多いほど、成功する可能性が高くなります。したがって、保留中のコミットに依存する場合は、検証とビジネス ルールの公開という観点から、よりシックなクライアントを計画してください。

その後、UI 内でデータを「保留中のコミット」に依存するものとしてマークまたはタグ付けすることで、ユーザーが引き続きデータを (さらに変更するために) 使用できるようにすることができます。オブジェクトまたは属性のメタ属性になります。もちろん、そのメタ属性を追加して使用すると複雑さが増しますが、アプリケーションによっては必要なユースケースになる場合があります。

クライアント側のコマンド キュー/履歴は、後続のイベントが最終的に失敗した保留中のコミットに依存している状況を処理するのに役立つ 1 つの方法かもしれません。つまり、保留中のコミットに依存するものはすべて、ロールアップできる履歴の一部である可能性があり、失敗した保留中のコミットに修正が加えられている間に保存され、アンロールされて、変更および再送信された保留中のイベントに再度適用されます。保留中のイベントがコミットに成功すると、後続のすべてのクライアント側の履歴が巻き戻され始め、キュー内の次のアイテムが送信され、現在保留中のイベントとしてマークされます。

于 2011-01-22T19:28:10.750 に答える