6

CQRS の一般的な概念は理解できましたが、実世界の問題に対処するためのサンプル コードやスライド デッキを超えて移動することに関しては、いくつかの質問があります。

  1. 検証

    データベースからの値のチェックを伴うコマンドの検証を行う必要がある場合、何をしますか? サービスに登録するには、固有のメール アドレスを入力する必要があります。私が聞いた議論の 1 つは、ユーザーが重複した電子メール アドレスを入力する可能性は非常に低いため、コマンドを処理するときにそれを処理し、「申し訳ありません」という電子メールを送信するか、パスワードのリセットを提案することです。したがって、このプロセスでは、検証のために readmodel を使用する必要がありません。しかし、コマンド ハンドラーで重複したケースをどのように処理するのでしょうか? それが重複していることをどのように知っていますか？readmodel をチェックしますか? 使いやすさを向上させるために、最初からそれを使用した方がよいでしょう。

  2. 機能の変更/バグ修正

    コマンドの動作方法を変更したり、バグを修正したりする必要がある場合はどうなりますか? 追加のみの哲学では、すべての古いコマンドとコマンド ハンドラーをどうすればよいでしょうか? それらの名前を _legacy に変更して非表示にすることはできません。そうしないと、イベントの逆シリアル化が機能しません。これに対処するためのエレガントなソリューションは何ですか?

ありがとう

4

1 に答える 1

4
  1. このトピックに関するさまざまな議論については、http://codebetter.com/blogs/gregyoung/archive/2010/08/12/eventual-consistency-and-set-validation.aspx および cqrs メーリング リストを参照してください。
  2. イベントのバージョン管理 (イベントのバージョン管理と同じ意味でコマンドのバージョン管理は必要ありません) についても、cqrs メーリング リストで議論されています。コマンドではなく、集約の現在の状態を取得するためにイベントが再生されます。このようにして、機能を進化させることができます。過去を変える方法はありませんが、現在/未来を変える方法はあります。奇妙なケースでは、別の方法で状態の追跡を開始する必要があり、明示的なコマンドを提供します。イベントの新しいプロパティについては、新しいデータベース列の場合と同様にデフォルトを指定してください。これらの新しい値がすでに存在する状態に基づいている場合は、明示的なコマンドをモデル化してそれらを事前計算します。利点は、これを非同期で実行できることですが、データベースのアップグレードではコードも変更する必要があります。それがどのように機能するかは、cqrs メーリング リストで尋ねたほうがよいでしょう。 1つの警告！イベント ソーシングを軽視しすぎないでください。CQRSだけで十分です。ほとんどの場合、CQRS で対応できるのに、CQRS+ES に切り替える人を見かけます。

groups.google.com/group/dddcqrs にアクセスして、サポートを受けてください。もう 1 つの便利なリソースは、cqrsinfo.com です。

于 2010-10-04T09:45:43.137 に答える