6

構築中のアプリケーション (複雑なビジネス ロジックを備えたオンライン ディスカッション システム) に CQRS を使用していますが、実装で気になる部分に到達しました。

ページビューをどのように処理すればよいですか? ユーザーがスレッドを表示した場合、それを追跡したいと思います。それを追跡したいので、コマンドとイベントを作成し、これを、表示しているオブジェクト (たとえば、それぞれ UserViewsThread と UserViewedThread) を担当する集約ルートに結び付ける必要があります。しかし、これは非常に非効率的であるように思われます。これ以外に、ディスカッション システム (フォーラム/スレッドの表示) の多くのユース ケースで集約ルートに到達する理由はありません。これを導入したので、ページのすべてのビューで追加のコマンド ディスパッチとイベント パブリッシュを行います。これは、スレッド集約の「スプールアップ」、イベントのシリアル化、およびイベントへの送信を担当します。出版社。

これを行うためのより良い方法が必要です。おそらく、コントローラー オブジェクトがイベントをディスパッチできるようにすることを考えていましたが、集約をバイパスすることで、動作をページビューに関連付けることができなくなりました。

もう 1 つの可能性は、ユーザーを認証する方法としてこれを使用するという考えです。UserViewsThread および UserViewsForum コマンドは、認証例外をスローして、ユーザーがこのアクションを実行できないことをコントローラーに知らせることができます。しかし、これらがイベントに変換され、私のイベント ストアに格納された場合、ページ ビューごとに作成された複数のイベントについて話していることになります。これは、パフォーマンスを非常に損なう可能性があります (ページ ビューごとにデータベース トランザクションが発生します...うーん)。そしてリソース管理。

あなたの彼の考えは何ですか？

4

4 に答える 4

2

CQRS を使用しても、アプリケーションとのすべての小さなやり取り (特にインフラストラクチャ関連の場合) がコマンド/イベント チェーンを渡さなければならないというわけではありません。ページビューの追跡は、個別に簡単に実装できる分野横断的な問題です。

読み取りレイヤーのクエリで、呼び出されるたびにテーブル内のそれぞれのビューモデルのカウンターを増やすだけです。

クエリが呼び出されるたびに状態を変更するコマンドの作成を開始すると、読み取りと書き込みが再び緊密に結合され、コマンドとクエリの分離の利点全体が失われます。そもそも CQRS を使用して 2 つの懸念事項を分離しています。

于 2012-11-18T11:38:29.470 に答える
1

これとほぼ同じことをしていました。しかし、このようにすべてを追跡するのは適切ではありません。読み取りは高速で、書き込みを行う必要はありません。

すべてのイベントに追跡オブジェクトを追加することになりましたが、もう一度行うことはないと思います。Google アナリティクスと同じように JavaScript を記述して、フロントエンドから別のコマンドを作成することを検討します。

また、追跡キューと通常のキューを分離します。

于 2012-11-18T10:06:12.507 に答える
1

セッションで追跡情報を取得し、時々サーバーに送信できます。

さらに、この情報を追跡するためにイベント ストアを備えた AR が本当に必要な理由は何だと思いますか? この情報を状態ベースのストレージに集約したでしょう。

于 2010-09-20T09:04:19.393 に答える
1

Web アプリのように見えるので、ページ ビューを処理する属性 (asp.net mvc/WebApi) を作成します。もちろん、この属性は、ストレージ内のページ ビューを更新するだけの INFRASTRUCTURE サービスを呼び出すだけです (追跡統計はドメインの一部ではないと思います)。簡単に言えば、サービスは永続性を更新する Dao を呼び出します (update Posts set pageviews=pageviews+1)。

もちろん、属性は、バックグラウンドで実行されるページビューを更新するコマンドを非同期に送信するだけでよいため、「書き込み」が実際に読み取りに干渉することはありません。

アプリに大量のトラフィックがある場合、または今後大量のトラフィックが発生する可能性がある場合は、次の永続化戦略をお勧めします: ページビューごとに行を追加するだけのテーブル PageViews(PageId,ViewsNumber,TimeStamp) を用意します。次に、X 分ごとに、Sum(ViewsNumber) GroupBy(PageId) where TimeStamp> oldTimestamp を実行するバックグラウンド サービスを用意します。ミリ秒単位の統計情報は得られませんが、頻繁に更新され、アプリの応答性は維持されます。

分析システムを構築している場合を除き、この問題はドメインの一部ではないと考えているため、AR、DDD、またはイベント ソーシングは必要ありません。あなたの場合、ページ統計はページに添付された情報であり、ページの一部ではありません。それらは、同じビューに実際に表示する読み取りモデルでのみ一緒に考慮されます。

于 2012-11-18T10:43:08.037 に答える