私からのコメント。 用語を選択するのは簡単ではなかったので、テキストの理解を改善するためにプロセスで翻訳を編集する準備ができています。
多くの人がCQRSとは間違っています。 彼らはCQRSをアーキテクチャと見なしていますが、そうではありません。 CQRSは、多くのアーキテクチャ機能を備えたシンプルなテンプレートです。 CQRSは究極の一貫性、イベント、またはメッセージングではなく、読み取りおよび書き込みのモデルではなく、イベントソースの使用でもありません。 CQRSが何であるかをいくつかの段落で説明し、それが他のテンプレートとどのように関係するかを考えます。
CQRSコマンドとクエリの責任分離
CQRSの操作を開始するとき、CQRSは以前は1つのオブジェクトであった2つのオブジェクトの作成であることを理解する必要があります。 分離は、メソッドがコマンドまたはクエリであるという事実に基づいています（Meyerはコマンドとクエリの分離で同じ定義を使用し、コマンドは状態を変更するメソッドであり、クエリは値を返すメソッドです）。
ほとんどの場合、CQRSについて話すときは、アプリケーションのサービスであるオブジェクトにアプローチすることを意味します。 次の擬似サービスコードを検討してください。
CustomerService
void MakeCustomerPreferred（CustomerId）
顧客GetCustomer（CustomerId）
CustomerSet GetCustomersWithName（名前）
CustomerSet GetPreferredCustomers（）
void ChangeCustomerLocale（CustomerId、NewLocale）
void CreateCustomer（顧客）
void EditCustomerDetails（CustomerDetails）
これでCQRSを使用すると、2つのサービスにつながります
CustomerWriteService
void MakeCustomerPreferred（CustomerId）
void ChangeCustomerLocale（CustomerId、NewLocale）
void CreateCustomer（顧客）
void EditCustomerDetails（CustomerDetails）
CustomerReadService
顧客GetCustomer（CustomerId）
CustomerSet GetCustomersWithName（名前）
CustomerSet GetPreferredCustomers（）
以上です。 これは、CQRSテンプレートの全体像です。 これ以上...この形式で説明するのは楽しいようですね。 この分離により、建築的な観点から興味深いものをもたらすことができます。 そして非常に重要なことは、2人が同じデータを使用し、さらに同じデータモデルを使用する必要があるため、精神遅滞プロセスを停止するのに役立ちます。
最大の利点は、コマンドとクエリを処理するときにさまざまなアーキテクチャプロパティを認識することです。たとえば、2つのサービスを異なる方法で配置できます。25台のサーバーで読み取りサービスをホストし、2台で書き込みサービスをホストできます。 コマンドとリクエストの処理は基本的に非対称であり、これらのサービスの対称的なスケーリングはあまり意味がありません。
タスクベースのUI
ジョブベースのユーザーインターフェイスは、CRUDベースのユーザーインターフェイスとはまったく異なります。 その中で、ユーザーが何をしているかを追跡し、彼の意図を表すチームを宣伝します。 CQRSはジョブベースのインターフェイスを必要としないことを強調したいと思います。 CRUDアプリケーションにCQRSを適用できます（ただし、たとえば、個別のモデルを作成するのははるかに困難です）。
ただし、実際に同様のインターフェイスを必要とするものが1つあります。これはドメインモデルです。
ドメインモデルのアプリケーションサービス層は、システムが実行できるタスクを表します。 これらは、ドメインオブジェクトにデータをコピーして保存するなどのプロセスだけではありません...オブジェクトの動作を忘れないでください。 先に進む前に、とにかくそうしたらどうなるか見てみましょう。
共通言語では、「作成」、「削除」、「変更」以外の動詞はありません。 そして、言語がそれだけである多くのドメインがありますが、システムを構築するためにドメインモデルの原則を使用するべきではありません。
このようなインターフェイスの概念はCQRSの一部となることを意図しておらず、ドメインに同様のコマンドがある場合があり、ユーザーの意図に従う必要があります。これは非常に重要です。 この更新は強制されましたか？ 違いは何ですか？ 自問した質問に依存します。
CQRSで誤解を招く次のテンプレートに進む
イベントソース
この用語を使用するとき、 ブリキで書かれたすべてを意味するものではないことを明確にしたいと思います。 現在の状態を一連のイベントとして保存し、これらの一連のイベントを繰り返すことでシステムの状態を再開することを指します...
方程式のコマンド側では、読み取りはもはやドメインの一部ではないため、イベントの保存は現在の状態を維持するための優れた方法です。 2つの別個のモデル（読み取り用のモデルと書き込み用のモデル）を決定すると値が増加し、それらを統合する必要がある場合は、イベントを介してこれを行う可能性が高くなります。 イベントは保存されているので、状態管理に1つのモデルを使用しないのはなぜですか？
メッセージングテンプレート
CQRSでこのアプローチを使用する必要はありません。 ただし、データモデルを共有する場合は、それらの間でメッセージングを使用する可能性が高くなります。この場合、新しい機会が現れるからです。
最後に、私は最後の「アプローチ」にアプローチしましたが、それを呼ぶのは好きではありませんが、実際には、人々がメッセージと連動するCQRS定義に入れる概念であるためです...
究極の一貫性
有限の一貫性の原則は、サービス間でもしばしば導入されます。 これは、多くの建築的衝動によるものです。 しかし、最大の利点は、スケーラビリティと可用性を向上できることです。 CAP定理を覚えていれば、一貫性がなければ他の2つの特性が強化されると言われています。 これは、モデルが分離されている場合にモデルに非常に適していますが、これは決してCQRS固有のプロパティではありません。
これで、CQRSは実際には非常に単純なテンプレートであることがわかります。 CQRSを中心に展開するのは、CQRSだけでなく、2つのサービスの統合のアーキテクチャ上の機能でもあります。 言い換えれば、最も興味深いのはCQRSテンプレートではなく、途中で下される決定です。 システムで使用された多くの興味深いソリューションがあり、そこで彼らはCQRSを使用することに決めました...しかし、これはCQRSだけではありません。
CQRS、ミッションベースのUI、イベントソース... ah
All Articles