Partilhar via

Aplicar abordagens CQRS e CQS em um microsserviço DDD no eShopOnContainers

  • Artigo

Gorjeta

Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Descarregar PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

O design do microsserviço de pedidos no aplicativo de referência eShopOnContainers é baseado nos princípios CQRS. No entanto, ele usa a abordagem mais simples, que é apenas separar as consultas dos comandos e usar o mesmo banco de dados para ambas as ações.

A essência desses padrões, e o ponto importante aqui, é que as consultas são idempotentes: não importa quantas vezes você consulte um sistema, o estado desse sistema não mudará. Em outras palavras, as consultas são livres de efeitos colaterais.

Portanto, você pode usar um modelo de dados de "leitura" diferente do modelo de domínio de "gravações" da lógica transacional, mesmo que os microsserviços de ordenação estejam usando o mesmo banco de dados. Portanto, esta é uma abordagem CQRS simplificada.

Por outro lado, os comandos, que acionam transações e atualizações de dados, mudam de estado no sistema. Com os comandos, você precisa ter cuidado ao lidar com a complexidade e as regras de negócios em constante mudança. É aqui que você deseja aplicar técnicas DDD para ter um sistema melhor modelado.

Os padrões DDD apresentados neste guia não devem ser aplicados universalmente. Eles introduzem restrições no seu design. Essas restrições fornecem benefícios como maior qualidade ao longo do tempo, especialmente em comandos e outros códigos que modificam o estado do sistema. No entanto, essas restrições adicionam complexidade com menos benefícios para ler e consultar dados.

Um desses padrões é o padrão Agregado, que examinaremos mais em seções posteriores. Resumidamente, no padrão Aggregate, você trata muitos objetos de domínio como uma única unidade como resultado de seu relacionamento no domínio. Nem sempre você pode obter vantagens desse padrão em consultas; ele pode aumentar a complexidade da lógica de consulta. Para consultas somente leitura, você não obtém as vantagens de tratar vários objetos como uma única agregação. Você só tem a complexidade.

Como mostrado na Figura 7-2 na seção anterior, este guia sugere o uso de padrões DDD somente na área transacional/atualizações do seu microsserviço (ou seja, conforme acionado por comandos). As consultas podem seguir uma abordagem mais simples e devem ser separadas dos comandos, seguindo uma abordagem CQRS.

Para implementar o "lado das consultas", você pode escolher entre muitas abordagens, desde seu ORM completo como EF Core, projeções do AutoMapper, procedimentos armazenados, visualizações, visualizações materializadas ou um micro ORM.

Neste guia e no eShopOnContainers (especificamente o microsserviço de pedidos) optamos por implementar consultas diretas usando um micro ORM como o Dapper. Este guia permite implementar qualquer consulta com base em instruções SQL para obter o melhor desempenho, graças a uma estrutura leve com pouca sobrecarga.

Quando você usa essa abordagem, todas as atualizações do seu modelo que afetam como as entidades são persistidas em um banco de dados SQL também precisam de atualizações separadas para consultas SQL usadas pelo Dapper ou quaisquer outras abordagens separadas (não EF) para consulta.

Os padrões CQRS e DDD não são arquiteturas de nível superior

É importante entender que CQRS e a maioria dos padrões DDD (como camadas DDD ou um modelo de domínio com agregados) não são estilos arquitetônicos, mas apenas padrões de arquitetura. Microsserviços, SOA e arquitetura orientada a eventos (EDA) são exemplos de estilos arquitetônicos. Eles descrevem um sistema de muitos componentes, como muitos microsserviços. Os padrões CQRS e DDD descrevem algo dentro de um único sistema ou componente; neste caso, algo dentro de um microsserviço.

Diferentes contextos delimitados (BCs) empregarão padrões diferentes. Têm responsabilidades diferentes, o que conduz a soluções diferentes. Vale a pena enfatizar que forçar o mesmo padrão em todos os lugares leva ao fracasso. Não use padrões CQRS e DDD em todos os lugares. Muitos subsistemas, BCs ou microsserviços são mais simples e podem ser implementados mais facilmente usando serviços CRUD simples ou usando outra abordagem.

Há apenas uma arquitetura de aplicativo: a arquitetura do sistema ou do aplicativo de ponta a ponta que você está projetando (por exemplo, a arquitetura de microsserviços). No entanto, o design de cada Contexto Delimitado ou microsserviço dentro desse aplicativo reflete suas próprias compensações e decisões internas de design em um nível de padrões de arquitetura. Não tente aplicar os mesmos padrões de arquitetura que CQRS ou DDD em todos os lugares.

Recursos adicionais

AnteriorSeguinte