CQ [R] Sモデルではコマンドをどの程度細かくする必要がありますか？

私は、WCFベースのSOAの一部をサービスバスモデル（おそらくnServiceBus）に移行し、いくつかの基本的なpub-subを使用してCommand-Query Separationを達成するプロジェクトを検討しています。

SOAやサービスバスモデルは初めてではありませんが、最近まで「分離」という概念は、すぐに使えるデータベースミラーリングとレプリケーションに限定されていたことを認めています。それでも、最終的に一貫性のあるシステムのすべての利点を提供する一方で、多くの明らかな欠点（特に、適切なトランザクションサポートの欠如）を回避するように見えるため、私はこのアイデアに魅了されます。

基本的にESBアーキテクチャ（少なくともMicrosoftの世界では）の第一人者であるUdi Dahanの主題について多くのことを読みましたが、彼が言うことの1つは本当に私を困惑させます。

より多くのフィールドを持つより大きなエンティティを取得すると、それらの同じエンティティを操作するアクターも多くなり、特定の時点で何かが何らかの属性に触れる可能性が高くなり、同時実行の競合の数が増加します。

[...]

CQRSの中核となる要素は、ユーザーインターフェースの設計を再考して、ユーザーの意図を捉えることができるようにすることです。これにより、ユーザーを優先させることは、ユーザーが移動したことや得たことを示すこととは異なる作業単位であるようになります既婚。上で見たように、データの変更にExcelのようなUIを使用しても意図はキャプチャされません。

- ウディダハン、CQRSを明確化

引用で説明されている観点から、その論理について議論することは困難です。しかし、SOAに関しては穀物に反するようです。SOA（および実際のサービス全般）は、粗雑なメッセージを処理して、ネットワークチャターを最小限に抑えるようになっています -他の多くの利点があります。

優れたメッセージキューイングを備え、RPCの手荷物のない高度に分散されたシステムを使用している場合、ネットワークチャターは問題になりませんが、問題を完全に却下することは賢明ではないようです。Udiは、すべての属性の変更（つまり、フィールドの更新）を独自のコマンドにする必要があるとほとんど言っているようです。これは、従来のウェブサービス。

高度にパラメーター化された適切なクエリ、テーブル値パラメーター、またはステージングテーブルへの一括挿入を行うと、SQL Serverの1つのバッチ更新に数秒の時間がかかる場合があります。これらの更新を一度に1つずつ処理するのは遅く、遅く、遅く、OLTPデータベースハードウェアはスケールアップ/スケールアウトに最もコストがかかります。

これらの競合する懸念を調整する方法はありますか？私はそれについて間違った方法で考えていますか？この問題には、CQS / ESBの世界でよく知られた解決策がありますか？

そうでない場合、コマンドの粒度の「適切なレベル」をどのように決定するのでしょうか。出発点として使用できる「データベース」のような3NFのような「標準」があり、慎重なプロファイリングが潜在的に重要なパフォーマンスの利点を示唆する場合にのみ逸脱しますか？

または、これはおそらく、さまざまな専門家によっていくつかの強い意見が表明されているにもかかわらず、実際には単なる意見の問題であるものの1つですか？

「すべての属性変更」のトピックについて

ポイントを逃したと思います。Udi Dahan氏は、ユーザーの意図をコマンドとして取り込むべきだと言っています。エンドユーザーは、顧客が移動したことを示すことができることに関心があります。コマンドが顧客識別、新しい住所（通り、通り番号、郵便番号などに分割）を含むコンテキストに応じて、オプションで新しい電話番号（移動する場合は珍しくありません-これらすべての携帯電話ではそうではないかもしれません） 。それはほとんど属性ではありません。より良い質問は、「コマンドをどのように設計しますか？」です。行動の観点からそれらを設計します。エンドユーザーが完了しようとしている各ユースケース、フロー、タスクは、1つ以上のコマンドでキャプチャされます。これらのコマンドでどのようなデータが使用されるかは、当然のことながら、それらについてより詳細に推論を開始します。注意が必要なのは、「コマンドを分割する必要があることを示している可能性があります。コマンドの粒度に関して、この標準を見つけられないことを願っています。いい質問ですね！

Udiが理解しようとしているメッセージは、CQRSは単なるCRUDだけではないということです。なぜこのレコードを作成したのですか？なぜこの記録を変更するのですか？削除されている/削除済みとしてマークされているのはなぜですか？

コマンドは、ユーザーがシステムで行うアクション/ユースケースに対応し、これを変更するだけでなく、アクションの意図を表現する必要があります。また、きめが細かいように見えるかもしれませんが、最初に表示されるよりもはるかに粗い場合があります。たとえば、ゴールドステータスへのアップグレードには、いくつかの属性の変更が含まれる場合があり、他の多くのアグリゲートが対応するイベントに応答して応答し、変更する場合もあります。

CQRSは、サービスレイヤーでビジネスの言語をキャプチャするためのものです。そのため、ゴールドステータスのアップグレードを行ったり、貨物が運送業者によって配達不能としてマークされたり、従業員が昇進した場合にUIが何を心配する必要はありませんテクノロジーグループのマネージャーに。技術的に言えば、今はイベントソーシングについて話していますが、あなたは私のドリフトを取得します。より明確なメッセージがありますが、それらは必ずしも標準のCUDよりもきめ細かいものではありません。