web-dev-qa-db-ja.com

CQRSおよびDDDの用語

CQRSとDDDは互いに関係しているわけではないので、どの用語がDDDに属し、どの用語がCQRSに属しているのか知りたいと思いました。 2つの概念は文献で一緒に使用されることが多いため、通常はそれらを混同しています。

私はどちらかのキャンプに行くと思う用語のこのリストを思いつきました。

DDD

  • ドメインモデル
  • 集約（および集約ルート）
  • 値オブジェクト、エンティティ、サービス
  • 境界付きコンテキスト
  • ユビキタス言語
  • イベント？

CQRS

  • コマンド（コマンドハンドラー）
  • イベント？ （イベントハンドラ？）
  • 佐賀県、プロセスマネージャー
  • モデルの読み取り/モデルの書き込み
  • 投影（異なる読み取りモデル）
  • 結果の一貫性

誰かが私を訂正（および/または説明）できますか？どこにありますか？

domain-driven-designcqrsevent-sourcingread-model
6
redhead

CQRSとDDDは別個の/直交する概念であり、用語をかなり右に分割したと思います。

[〜＃〜] ddd [〜＃〜] の下のイベントはドメインイベントと呼ばれ、CQRSでよく言及されるメッセージングイベントとは多少異なります。通常、メッセージングイベントは Event Sourcing と関係があります。

CQRSカテゴリは、多数のパターンの集まりであり、実際にCQRSに定義されるのはそのうちの1つ（モデルの読み取り/モデルの書き込み）のみです。

  • Messaging 、コマンドおよびイベントとして実装されます。メッセージングは​​、RPCのようなものに対して、多くの柔軟性を提供します。メッセージは、単なる要求またはイベントデータであり、検査、優先順位付け、キューイング、ノード間での分割、転送、再試行、サブスクライブなどが可能です。逆に、失われたり、汚染されたりすることもあります。

  • Saga および Process Manager は しばしば同じ意味で使用されます プロセスマネージャを参照する場合。どちらも、通常はスケーラビリティを維持するために、分散トランザクションを回避するための戦略です。

  • Projectionはずっと前に戻ります。あなたはおそらくこれをSQLから最もよく知っています。 SELECT expr [as name]ステートメントは、SQLのベースとなる relational algebra の射影演算です。射影は、基礎となるデータのサブセットまたは変換にすぎません。

    CQRSのコンテキストでは、投影は通常ビュー（別名読み取りモデル）を指します。技術的にはイベントソースの集計もプロジェクションですが、ビューと同様に、構造化モデルに変換されたイベントストリームです。

  • 読み取りモデルと書き込みモデルの分離は、 CQRSの基本的な定義 です。ビュー（読み取り）に必要なデータは書き込みに必要なデータとは異なるため、CQRSは役立ちます。従来の3層システム（プレゼンテーション、ビジネス、データレイヤー）では、多くの場合、3つのレイヤーすべてで同じクラスが使用されています。複雑さが増すと、1つのレイヤーだけで使用される追加のフィールドが作成されますが、すべてのレイヤーで精神的な重みが追加されます。 「このコレクションに何かを追加しました。ここでDisplayCountを更新する必要がありますか、それともビューで更新しますか？このDisplayCountを永続化する必要がありますか、それともビューで毎回再計算しますか？待ってください、なぜDisplayCountは文字列ですか？」

    読み取りと書き込みのニーズは十分に異なるため、さまざまなオブジェクトが問題を切り分けられることを保証します。これにより、ビジネスオブジェクトをビューオブジェクトにマッピングできます。ビューオブジェクトは、おそらくCQRSの形式です。 （これは、CQRSを使用しないDDDシステムでも発生し、ドメインモデルからビューにマッピングされます）。ただし、CQRSを要求する場合、多くの場合、書き込みモデルを読み込んで読み取りモデルにマッピングするのではなく、読み取りモデルと書き込みモデルの両方を永続化していることを意味します。通常、特定の書き込みモデルには複数の読み取りモデルがあり、さまざまなUI画面/レポート/ビューの特定のニーズに対応します。

  • 最終的な整合性もCQRSに固有ではありません。定期的に実行されるレポートを作成すると、いつでも一貫性のある読み取りモデルが作成されます。それがCQRSと話されるとき、それは通常ほとんど/すべての読み取りモデルが最終的に一貫していることを意味します。これはCQRSではオプションです。完全に一貫した方法でCQRSを使用できます。これにより、IOの負担が読み取りから書き込みに単純に移行します。 IOは読み取りによって支配される可能性が高いため、これ自体はおそらくほとんどのシステムにとって大丈夫なトレードオフです。

    単一のデータモデルを持つシステムは、書き込み（ 正規化 ）用に最適化されており、読み取りにはコストがかかります（SQLのJOINなど）。 CQRSを使用すると、de正規化された個別の（おそらく複数の）読み取りモデルを作成することで、安価な読み取りに向けてトレードします（すべての必要なデータが各読み取りモデルに入れられるため、 JOINは必要ありません）。完全に一貫したシステムでは、読み取り/書き込みの一貫性を維持するために、書き込みモデルとすべての読み取りモデルを同時に更新する必要があります。書き込みパフォーマンスと読み取りパフォーマンスをトレードオフしています。

    最終的な整合性を入力します。これにより、読み取りと書き込みが安価になり、読み取りモデルは書き込みモデルよりもわずかに遅れます（最終的には整合性があります）。これは、実際に読み取ったモデルを更新する帯域外プロセス（非正規化と呼ばれることが多い）が原因です。

多くの人が、これらのパターンとCQRSを組み合わせた「CQRSシステム」を開発しています。ただし、CQRSパターンは実際には、読み取りモデルと書き込みモデルを分離するだけです。これは、結果整合性、イベントソーシング、プロセスマネージャー、メッセージングなどがあることを意味するものではありません。ただし、前述のパターンはCQRSと相乗効果があり、基本的にはそれをさらに活用するための漸進的な最適化です。

また、CQRSは別のパターン Command-Query Separation に基づいていますが、さらに一歩進んでいます。

編集：ドメインイベントとイベントソーシングに使用されるイベントの違いに関する詳細な説明については、 この従来のGreg Youngの投稿 を参照してください。

13
Kasey Speakman

いくつかの考え：

DDD

  • ドメインモデル
  • 集約（および集約ルート）
  • 値オブジェクト、エンティティ、サービス
  • 境界付きコンテキスト
  • ユビキタス言語
  • Domainイベント

CQRS

  • コマンド（コマンドハンドラー）
  • イベント？ （イベントハンドラ？）代わりにイベントソーシングを参照
  • 佐賀県、プロセスマネージャー隣接するアプローチのソートですが、「コア」CQRS自体ではありません
  • モデルの読み取り/モデルの書き込み
  • 投影（異なる読み取りモデル）
  • 結果の一貫性ここでは発明されていませんが、間違いなく重要な基本概念
0
guillaume31

ほとんどの用語は相互に関連しているため、両方のドメインに属します。実際には、 Martin Fowlerによる書き込み

CQRSは、システム全体ではなく、システムの特定の部分（DDD用語では境界付きコンテキスト）でのみ使用する必要があります。

これはDDDアプリケーションを実装する方法であり、そのため用語が混在しています。 Udi DahanはCQRSで 良い書き方 を持っていると言っています

間違いなく、トランザクションスクリプトによって処理されるコマンドもあれば、ドメインモデルを使用するコマンドだけでなく、テーブルモジュール（別名アクティブレコード）を使用するコマンドもあるでしょう。イベントソーシングは、もう1つの可能な実装です。

本当に必要な場合は、DDD用語でドメインについて話し、サガ、コマンド、読み取り/書き込みモデルについて話すのを避けることができます。これは、基礎となる永続化のテーブルや主キーについて話すことなく、アプリケーションについて話すことができるのと同じです。メカニズムですが、2つを混合することがあります。用語をDDDまたはCQRSバスケットに入れることにあまり焦点を当てません...

0
JDT