Com base em CQS, o CQRS (Command Query Responsibility Segregation) é um padrão utilizado para separar as responsabilidades de leitura e escrita nos bancos de dados. E com isso é possível evitar problemas de incompatibilidade e inconsistência nas informações.
(Assista em 14min30seg)
Em tese, se você usa o mesmo banco de dados para qualquer coisa que você faz, existe o risco de gerar um grande gargalo de informações. Mas quem trabalha com CQRS faz uma separação muito clara entre o que é um “comando” de escrita; e uma “query” de leitura. O comando é a intenção de executar uma transação, que representa uma mudança de estado. Ou seja, ao criar um novo cliente no seu sistema, você envia o comando que vai realizar essa operação e salvá-la no banco de dados.
Mas quando você tem diversas aplicações que vão utilizar esses clientes, isso também gera uma grande quantidade de dados de leitura e escrita que podem sobrecarregar o seu banco de dados. Esse é um detalhe importante, pois a forma pela qual você grava as informações, que você estrutura e organiza no seu banco de dados, são feitas de um jeito.
A questão é que se as consultas feitas nele estiverem num formato diferente, você teria que fazer diversos left joins, queries e subqueries no mesmo ponto. E, por consequência disso, você também teria um grande overhead de dados. Então nesse momento você deve considerar a criação de dois bancos de dados, sendo que num você vai escrever e no outro você vai consultar as informações.
Dessa forma você pode separar as suas consultas e o esquema do seu banco de dados pode ser, por exemplo, no SQL, mas de um jeito que te facilite pegar os dados num formato que você está esperando.
Basicamente você faz essa separação, sendo que de um lado do sistema você escreve e aciona os comandos, além de utilizar as regras de negócio com essa finalidade, que são os próprios comandos. E você prepara o outro lado do sistema para realizar consultas, fazer chamadas e recuperar informações.
Quando utilizar CQRS?
Nem todos os sistemas precisam desse nível de complexidade, já que nesse caso você teria que lidar com consultas em formatos muito específicos. E, na maioria das vezes, o seu velho banco de dados vai funcionar muito bem. Às vezes nós trabalhamos em sistemas que escrevem e leem muito no banco de dados, portanto “segregar” essas responsabilidades pode ser a melhor opção.
Então em sistemas muito críticos, que retém um grande volume de acessos, essa situação pode se tornar muito crítica. E facilitar o acesso a esses dados vai ser muito vantajoso.
Event Sourcing
O CQRS também lida com Event Sourcing, que é basicamente a fonte de qualquer evento ou ação tomada no sistema. Com esse histórico você pode consultar quaisquer mudanças que fizeram nele. Por exemplo: se houve a alteração de um nome, você consegue verificar quando isso aconteceu e o que foi alterado.
Isso é muito vantajoso, principalmente quando você trabalha em sistemas que precisam de uma grande auditoria e seguir diversas regras de compliance.
Pensando nesses aspectos você pode implementar o CQRS no seu dia a dia, mas não se esqueça de considerar as situações nas quais isso vai ser realmente necessário e vantajoso para o seu trabalho.
Assista ao vídeo completo no começo desse post para mais informações. Veja também: O que é Fault Injection?
Se você quer entender como CQRS pode transformar sua aplicação, clique aqui e solicite contato conosco.
Confira nosso canal do youtube. Tem esse e vários outros conteúdos interessantes pra você.
