Compartilhar via

Aplicar padrões de CQRS e DDD simplificados em um microsserviço

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

miniatura da capa do eBook sobre arquitetura de microsserviços do .NET para aplicativos .NET em contêineres.

O CQRS é um padrão de arquitetura que separa os modelos de leitura e gravação de dados. O termo relacionado Command Query Separation (CQS) foi originalmente definido por Bertrand Meyer em seu livro Object-Oriented Software Construction. A ideia básica é que você pode dividir as operações de um sistema em duas categorias fortemente separadas:

  • Consultas. Essas consultas retornam um resultado e não alteram o estado do sistema e estão livres de efeitos colaterais.

  • comandos. Esses comandos alteram o estado de um sistema.

O CQS é um conceito simples: trata-se de métodos dentro do mesmo objeto que são consultas ou comandos. Cada método retorna o estado ou modifica o estado, mas não ambos. Até mesmo um único objeto padrão de repositório pode estar em conformidade com o CQS. O CQS pode ser considerado um princípio fundamental para o CQRS.

A Segregação de Responsabilidade de Comando e Consulta (CQRS) foi introduzida por Greg Young e fortemente promovida por Udi Dahan e outros. É baseado no princípio do CQS, embora seja mais detalhado. Ele pode ser considerado um padrão com base em comandos e eventos, além de, opcionalmente, em mensagens assíncronas. Em muitos casos, o CQRS está relacionado a cenários mais avançados, como ter um banco de dados físico diferente para leituras (consultas) do que para gravações (atualizações). Além disso, um sistema CQRS mais evoluído pode implementar Event-Sourcing (ES) para o banco de dados de atualizações, de modo que você armazenaria apenas eventos no modelo de domínio em vez de armazenar os dados de estado atual. No entanto, essa abordagem não é usada neste guia. Este guia usa a abordagem CQRS mais simples, que consiste apenas em separar as consultas dos comandos.

O aspecto de separação do CQRS é obtido agrupando operações de consulta em uma camada e comandos em outra camada. Cada camada tem seu próprio modelo de dados (observe que dizemos modelo, não necessariamente um banco de dados diferente) e é criado usando sua própria combinação de padrões e tecnologias. Mais importante ainda, as duas camadas podem estar dentro do mesmo nível ou microsserviço, como no exemplo (microsserviço de pedidos) usado para este guia. Ou podem ser implementados em microsserviços ou processos diferentes para que possam ser otimizados e dimensionados separadamente sem afetar uns aos outros.

CQRS significa ter dois objetos para operações de leitura e escrita, enquanto em outros contextos há apenas um. Há motivos para ter um banco de dados de leituras desnormalizado, sobre o qual você pode aprender na literatura CQRS mais avançada. Mas não estamos usando essa abordagem aqui, em que o objetivo é ter mais flexibilidade nas consultas em vez de limitar as consultas com restrições de padrões DDD, como agregações.

Um exemplo desse tipo de serviço é o microsserviço de ordenação do aplicativo de referência eShopOnContainers. Esse serviço implementa um microsserviço com base em uma abordagem CQRS simplificada. Ele usa uma única fonte de dados ou banco de dados, mas dois modelos lógicos mais padrões DDD para o domínio transacional, conforme mostrado na Figura 7-2.

Diagrama mostrando um microsserviço de CQRS e DDD simplificados de alto nível.

Figura 7-2. Microsserviço simplificado baseado em CQRS e DDD

O microsserviço "Pedidos" lógico inclui o banco de dados de Pedidos, que pode estar, mas não precisa estar, no mesmo host do Docker. Ter o banco de dados no mesmo host do Docker é bom para desenvolvimento, mas não para produção.

A camada de aplicativo pode ser a própria API Web. O aspecto de design importante aqui é que o microsserviço dividiu as consultas e ViewModels (modelos de dados especialmente criados para os aplicativos cliente) dos comandos, modelo de domínio e transações seguindo o padrão CQRS. Essa abordagem mantém as consultas independentes de restrições e restrições provenientes de padrões DDD que só fazem sentido para transações e atualizações, conforme explicado em seções posteriores.

Recursos adicionais

AnteriorPróximo