Command-Query Responsibility Segregation (CQRS) の一般的背景は，同一のデータセット上で作業する複数ユーザに対する共同ドメインである - Udi Dahan氏は，CQRSについて論じたインタビューの中で，このように説明した。サービス指向アーキテクチャの権威であり，NServiceBusの開発者である氏にとってCQRSは，パターンというよりも，思考のアプローチないしスタイルなのだ。パターンと呼んでしまうと，往々にしてソリューション部分のみに関連付けられる。CQRSを論じる上で最も重要な部分であるにも関わらず，コンテキスト部分が忘れられることが，あまりにも多いのだ。
アプリケーションの多くは，ユーザがデータの一部で作業し，同じデータを使うユーザは他に存在しないという，比較的シンプルなビジネスドメインを保持する。この場合ユーザは，自分が書き込んだものを直接読むことが可能だ。CQRS，そして結果整合性(eventual consistency)を用いる場合，そのようなドメインでは，エンドユーザが見たいと望むものを再生するのは難しい作業になる。CQRSを採用する場合のコンテキストがいかに重要か，それが適切でなければどうなるのか，ということを示す一例だ。対照的に，複数ユーザがデータを操作するコラボレーティブなドメインでは，他のユーザが同じデータを操作したかどうかを知る方法がないため，データを読み出した時に期待できる内容は，単一ユーザのドメインの場合とは違うものになる。
一般的にコラボレーティブなドメインでは，レコード数が多くなる傾向がある。個々のレコードは比較的小さいものの，多数の操作履歴やインタラクションのため，結果的にデータのボリュームは巨大なものになる。在庫のドメインはその古典的な例だ。積み荷が入荷し，購入品が出荷され，ストック容量や購入可能数，オーダの提供時間と言った問い合わせが実行される。さらに大容量な例としては，株式購入がある。このドメインは，大容量を扱うように基本から設計されていると同時に，複数のパーティとともに動作するようにモデル化されてる。
氏はCQRSシステムについて，特別な意図を持たずに開発されていることに注意を促している。CQRSはアプリケーション全体に適用可能なものではない。アプリケーションの一部がCRUDを行うシングルユーザ向きで，他がCQRSに適しているような場合もあり得るのだ。
現在の氏は，データモデリングを非常に重視している。また，開発者が自らのインメモリオブジェクトモデルのみに注意を集中しようとする時に，舞台裏にある実際のデータモデルのすべてを処理する訳ではないORMは，有害な存在であると考えている。コラボレーティブなドメインでは，データモデルを始めとする別の作業方法を取らざるを得ない，と氏は述べている。DDD派を自認する一方で，場合によってはドメインモデルを止めて，データモデルに注力することも必要だという考えなのだ。これによって，ドメインモデルが本当に必要なのか疑問に思えるほど，データモデルがシンプルになることも非常に多いと，氏は自身の経験から述べている。