7

私は CQRS/イベント ストア システムに取り組んでいます。現在、私が使用しているパターンは、コマンドが同期するためのものです。つまり、ユーザー インターフェイスは、コマンドが完了するまで操作を完了として表示せず、成功/失敗がユーザーに表示されます。コマンドの実行中、生成されたすべてのイベント (集約ルート Y で発生したアクション X など) は、永続ストレージに格納されます。

私が読んだ CQRS の説明はすべて、コマンド ストレージを実装しています。これが私の状況で必要かどうか疑問に思っています。

もう 1 つ注意してください。実行時間の長いコマンド タイプのアクションが多数あるため、操作をイベントを生成するコマンドに分割し、イベントがさらに多くのコマンドを発行するようにしました。コマンドは、集約ルートの状態に基づいてべき等です。これが答えにどのように影響するかはわかりませんが、指摘する価値はあります。

4

2 に答える 2

8

  1. リグレッション テスト 各開発イテレーションの後、本番環境からコマンド ログを取得して再実行し、生成されたイベント ストリームを本番環境のものと比較できます。それらが異なる場合-ロジックに回帰があります。

  2. メッセージ フローの視覚化と分析。

于 2012-04-19T06:44:10.827 に答える
4

イベント ソーシングなしで見た Cqr の例は、データの状態がどのように発生したかを示すイベントではなく、システムの状態を格納する通常のリレーショナル データベースです。「コマンドソーシング」は私にとって新しい概念であり、コマンドハンドラーは時間の経過とともに変化する可能性があるため、正しくないようです。コマンド ハンドラーのロジックを変更すると、コマンドの再生時にコマンドが失敗する可能性があります。オブジェクトのプロパティが直接設定されているため、イベントの再生にはこの問題はありません。

于 2012-04-18T21:16:15.157 に答える