Udi Dahan explicou em uma entrevista que um contexto usual para o Command-Query Responsibility Segregation (CQRS) é caracterizado por um domínio colaborativo com múltiplos usuários trabalhando sob o mesmo conjunto de dados. Para Dahan, especialista em Arquitetura Orientada a Serviços e criador do NServiceBus, o CQRS é mais uma abordagem ou uma maneira de pensar do que um padrão. Quando colocado como padrão, frequentemente acaba por ser associado à parte da solução, sendo o contexto geralmente esquecido, mesmo sendo a parte mais importante se tratando de CQRS.
Muitas aplicações possuem domínios de negócios relativamente simples, em que um desenvolvedor trabalha de maneira isolada sob um conjunto de dados, o que faz com que o usuário espere ler exatamente o que ele acabou de gravar. Quando se trabalha com CQRS, e consistência eventual nesse domínio, o desenvolvedor terá dificuldades para simular o que o usuário visualizará, pois o CQRS não é a melhor opção para esse contexto, tem-se aí um exemplo do quão importante é o contexto quando se trabalha com CQRS. Porém, quando tem-se um domínio colaborativo com diversos usuários modificando o mesmo conjunto de dados, é impossível saber qual modificação interferirá na outra e, logo, a expectativa do usuário final sob o que será lido é diferente do contexto de único usuário.
Normalmente, domínios colaborativos tendem a ter grandes quantidades de registros, cada um separadamente pequeno, porém resultando em um grande volume de dados, com muitos registros de histórico e de interações. Um exemplo clássico é o domínio de inventário, com vários carregamentos entrando, compras saindo, e questões como - qual o tamanho atual do estoque? O quanto pode ser comprado? E o tempo de entrega de um determinado pedido? Um exemplo que envolve grandes volumes de dados é o caso de compra de ações. Um domínio que é estruturado para lidar com grandes volumes e modelado para trabalhar com múltiplos participantes.
Dahan destaca que a intenção nunca foi construir sistemas CQRS. O CQRS nunca foi aplicável para uma aplicação como um todo; parte do sistema pode ser usuários únicos realizando operações do tipo CRUD, com outras partes mais colaborativas e alinhadas ao CQRS.
Atualmente, Dahan enfatiza muito a modelagem de dados. Ele acredita que o Mapeamento Objeto-Relacional (do inglês Object/Relational Mapping - ORM) causou um pouco de dano fazendo os desenvolvedores focarem somente no modelo de objetos, não importando com o real modelo de dados. Ele afirma que no domínio colaborativo é necessário trabalhar de outra maneira, começando com o modelo de dados. Ele se vê como um profissional voltado para o Domain-Driven Design (DDD), porém acredita que as vezes é necessário deixar o modelo de domínio de lado e focar na modelagem dos dados. Em sua experiência, isso leva a um modelo de dados simples o bastante para se perguntar a verdadeira necessidade de um modelo de domínio.