2012-04-18 7 views
5

私はCQRS /イベントストアシステムに取り組んでいます。現時点では、私が使用するパターンはコマンドが同期することです。つまり、コマンドが完了して成功/失敗がユーザーに示されるまで、ユーザーインターフェイスは完了した操作を表示しません。コマンドの実行中に、生成された全てのイベント(例えば、集団ルートY上で発生したアクションX)が耐久記憶装置に記憶される。CQRS/ESシステムにコマンドを格納する利点は何ですか?

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

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

おかげで、私は調達イベントなしで見てきたCqrsの エリック

+0

コマンドを格納する実装の例をいくつか提供できますか?私が見たほとんどの例では、コマンドの結果として生成されたイベントしか格納されません。 –

+0

私はフレームワークを持っていませんが、少なくとも私が理解している限り、イベントソースを持たないCQRSは再生のためのレコードコマンドを持っています。 –

+0

私はセキュリティについて少し気になります。クリアテキストのパスワードを含むChangeUserPasswordのようなコマンドで何をする予定ですか? – Kimble

答えて

6
  1. 回帰テスト は、それを再実行し、生産上の1で生成イベントストリームを比較します。彼らが違うなら、あなたの論理に回帰があります。

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

4

例はむしろ、データの状態は、約来た方法を示すイベントよりも、システムの状態を保存する通常のリレーショナルデータベースです。 「コマンドソーシング」は私の新しいコンセプトであり、コマンドハンドラは時間の経過とともに変化する可能性があるため、正しいとは思われません。コマンドハンドラロジックを変更すると、再生時にコマンドが失敗する可能性があります。オブジェクトのプロパティが直接設定されているため、イベントの再生にはこの問題はありません。本番環境からコマンドログをつかむことができる反復のすべてのdevの後

+0

これは意味があります - ありがとう! –

関連する問題