Análise dos benefícios dos padrões CQRS e Event Sourcing em arquitetura de microsserviços

1. Resumo

O presente trabalho trata avaliar os benefícios dos padrões CQRS e Event Sourcing em ambientes desacoplados pela arquitetura de microsserviços. Visa também mostrar o que são e como eles podem adicionar como complemento para a utilização de microsserviços. No entanto, é observado através de pesquisas, que muitos desenvolvedores seguindo as exigências de mercado de software optam pelo uso da arquitetura, eventualmente encontram dificuldades ao trabalhar com serviços fracamente acoplados. Posto isso, a contrariedade indicada se dá pela falta de conhecimento sobre técnicas fundamentais que complementam a arquitetura de microsserviços. CQRS e Event Sourcing integram mecanismos imprescindíveis à comunicação entre diferentes serviços, gerenciamento e otimização das operações de dados, ainda no domínio de negócio. Para a realização do trabalho foram utilizadas como metodologias bibliográficas sobre estilo e padrões de arquiteturais e modelagem de software de especialistas acerca do assunto proposto. Assim, este trabalho tem a intenção de apresentar de forma abstrata da tecnologia e linguagem de programação, sendo um recurso conceitual para profissionais de softwares a trabalhar com a arquitetura de microsserviços.

Palavras-chave: CQRS; Event Sourcing; Microsserciços; Padrão de Design; Arquitetura; Otimização.

Abstract

This paper aims to evaluate the benefits of CQRS and Event Sourcing standards in environments decoupled by the microservices architecture. It also aims to show what they are and how they can add to the use of microservices. However, it is observed from research that many developers following the software market requirements choose to use architecture, eventually encountering difficulties when working with loosely coupled services. That said, the indicated setback is due to the lack of knowledge about fundamental techniques that complement the microservices architecture. CQRS and Event Sourcing integrate essential mechanisms for communication between different services, management and optimization of data operations, even in the business domain. For the accomplishment of the work were used as bibliographic methodologies on style and architectural patterns and software modeling of experts on the proposed subject. Thus, this paper intends to present abstractly the technology and programming language, being a conceptual resource for software professionals working with the microservices architecture.

Keywords: CQRS; Event Sourcing; Microservices; Design Pattern; Architecture; Optimization.

*Graduado em Análise e Desenvolvimento de Sistemas pela Universidade Estácio de Sá – UNESA. Desenvolvedor .NET. E-mail: fabricio.ramoss@hotmail.com

2. Introdução

Ao longo da última década as empresas desenvolvedoras de software de todo o mundo vivem uma realidade sobre escalabilidade. A capacidade de recursos que um sistema de software pode se adaptar é uma exigência do mercado e determina o quanto preparado uma aplicação está. As principais organizações, como Amazon, Netflix, Apple, eBay, Paypal, Soundcoud, entre outras, trabalham com grandes estruturas de sistema, oferecendo serviços complexos e de alto volume de dados. Esses dados são criados, processados e distribuídos para diversos contextos do sistema através da arquitetura de microsserviços.

A arquitetura de microsserviços é cada vez mais presente nas atuais aplicações, como uma solução para que projetos de software possam suportar múltiplas tecnologias e linguagem de programação entre outras características. No entanto, ao trabalhar com microsserviços faz com que o nível de complexidade no processo de desenvolvimento aumente exponencialmente. Questões fundamentais de como os dados irão ser gerenciados em múltiplos ambientes de serviços e banco de dados, que se comunica entre diferentes contextos, isso ainda é uma barreira a ser ultrapassada. Eventualmente, buscar possíveis soluções para resolver tais problemas da arquitetura de microserviços torna-se um desafio, pois se entende que é necessário suprir tais limitações na abordagem de microsserviços, como: O banco de dados deve pertencer a um exclusivo serviço, sendo cada serviço totalmente independente e modular entre si.

Por isso, partindo dessa ideia, buscar maneiras de resolver essas limitações sobre a comunicação na arquitetura de microsserviço, é fundamental para que se possa manter os dados e informações de forma coesa e sempre disponíveis quando necessários. Segundo pesquisa feita pela empresa alemã Camunda (2008), especialista em desenvolvimento de software, que tem como clientes NASA, Universal Music e outras, 50 % das respostas sobre as dificuldades encontradas na implementação de microsserviços é por motivos da comunicação entre os serviços. Como pode ser observada, a arquitetura de microsserviços, apesar de oferecer todas as características positiva sobre o desacoplamento, precisa de meios para dar conta dessas limitações e vencer em seus objetivos.

Figura 1: As dificuldades sobre microsserviços

Fonte: Camunda (2008)

Levando o problema acima apresentado a um cenário de microsserviços que não faz o uso de soluções eficazes, e para que possa ter uma melhor compreensão da importância que é buscar melhorias para a arquitetura de microsserviços será criado um exemplo. Imagine um sistema que possui múltiplos serviços, e cada serviço gerenciando suas entradas e saídas de dados com seus específicos bancos de dados e outros serviços em um setor de uma empresa. Nele será realizada uma modificação em uma variável do cadastro de um funcionário da empresa. Em outro setor, que também tem acesso ao sistema executa em outro serviço uma ordem de verificação ao mesmo tempo do primeiro setor sobre a variável alterada.

Dessa maneira, como garantir coerência nesse pedido de consulta? Como o sistema deve gerenciar a comunicação entre os diferentes serviços que fazem operações simultâneas ao banco de dados em uma arquitetura de microsserviços, lembrando que cada serviço deve possuir seu próprio banco de dados? Infelizmente torna-se esperado que, com apenas a arquitetura de microsserviços, em alguns momentos ocorram conflitos no tráfego dos dados, já que a arquitetura por si não gerencia a comunicação de forma eficaz. Entre as diferentes formas de solucionar essa falha estão: Microsserviços com banco de dados compartilhado – Diferentes serviços utilizando o mesmo banco de dados, quebrando o conceito de modularidade de microsserviços e como resultado toda a atualização em um modelo de dados de um serviço, afetará também a do outro serviço. Microsserviços com banco de dados dedicados – Caso ocorra nessa abordagem uma exclusão em um modelo que se relacione com outro através de protocolo HTTP, outro modelo agregado ao primeiro deverá também ser excluído da base de dados.

Figura 2: Exemplos de comunicações entre microsserviços e banco de dados

Fonte: DZone (2018)

Em relação à problemática apresentada acima, alguns especialistas e autores na área de desenvolvimento de software, criaram métodos no intuito de solucionar falhas usando uma abordagem de manipulação de mensagens e como um sistema deve enxergar os dados e suas modificações de estados. Além de auxiliar a comunicação, torna-se um complemento indispensável na implementação de microsserviços, trazendo resultados eficazes diante as falhas descritas anteriormente. Através de melhorias no gerenciamento de comunicação entre serviços em um sistema, os padrões arquiteturais CQRS e Event Sourcing dão ao estilo arquitetural de microsserviços formas otimizadas de tráfego de dados configurados individualmente, criação de filas assíncronas de mensagens e armazenamento de dados como eventos. Todas essas características serão meio de orquestrar a comunicação dentro de uma arquitetura de microsserviços.

Os objetivos desse artigo apoiam-se no estudo da relação dos benefícios do uso dos padrões arquiteturais CQRS e Event Sourcing, difundidos por Greg Young (2010), Udi Dahan (2009) e Martin Flower (2005), todos esses especialistas na área de desenvolvimento de software, e difusores do conhecimento. Serão usados padrões CQRS e Event Sourcing para solucionar problemas encontrados em sistemas desacoplados, além de otimizar a relação dos dados e como eles devem ser enxergados através da sua usabilidade. O fator predominante para que esse trabalho tenha sido executado é a demanda por excelência na hora de manter a escalabilidade exigida pelo mercado de software, não sendo apenas um requerimento das grandes organizações, mas também de corporações menores no ramo que tem a intenção de sucesso.

3. Arquitetura de Microsserviços

O termo arquitetura de microsserviços surgiu em um evento sobre arquitetura de software em 2011. Sendo uma maneira de pensar sobre soluções de escabilidade e desenvolvimento distribuição, auxiliando múltiplas equipes a trabalhar ao mesmo tempo. A criação da arquitetura de microsserviços é uma variação de outro conceito arquitetural, o SOA. A Arquitetura Orientada a Serviços (SOA) teve seu auge em 2007, e atualmente perdendo sua relevância para o uso de microsserviços. Por ter sido muito impulsionada por grandes empresas tradicionalistas, dessa forma consolidando padrões complexos e políticos, tornam-se pouco flexíveis. Diferente do SOA, a arquitetura de microsserviços é mais adaptável e fácil de implementar pela falta de padrões pré-estabelecidos, e assim se encaixando em diferentes tipo de projetos (O’Grady, 2007).

Indo mais a fundo sobre microsserviços, é possível encontrar conceitos falhos sobre a arquitetura, mas também definições até sobre a etimologia da palavra microsserviço como uma solução de desenvolvimento de software. O entendimento etimológico de “micro”, do grego mikros, que significa algo muito pequeno em uma escala negativa muito grande, não ajuda a expressar da maneira correta o que é microsserviço. Caso seja idealizado que microsserviços são serviços muito pequenos, essa simplicidade tornará o sistema em microsserviço em com conjunto de falhas, principalmente por causar uma falta de visibilidade sobre as regras de negócio do sistema. Eric Evans (2015) afirma que uma aplicação em microsserviços deve ter suas delimitações de serviços bem estabelecidas por contextos, e não apenas em fragmentar ao máximo possível as funções que serão executadas no sistema.

Microservices are na approach to distributed system that promote the use of finely grained services with their own lifecyles, which collaborate together. Because microservices are primarily modeled around business domain, they avoid the problems of tradicional tiered architectures (NEWMAN, 2015).

É essencial para que se entenda o impacto da arquitetura de microsserviços nas aplicações. Para que se possa fazer entender a idéia de implementar a arquitetura de microsserviços, é essencial que façamos uma comparação com o estilo arquitetural clássico, ou também conhecido como estrutura monolítica. Um sistema construído com o conceito monolítico nada mais é do que uma única base de códigos e tecnologias que compõe todo o sistema. Essa maneira de criar software foi muito utilizada no passado e ainda é, principalmente quando as definições do que será futuramente o sistema é estabelecida na criação da aplicação e analisada como sendo um sistema simples. As dificuldades encontradas na programação monolítica são: dificuldade de visualização do código, atrapalhando os testes e a manutenções, onde qualquer alteração no sistema já em uso envolve a criação e uma nova disponibilização de versão de todo o sistema. E quando a intenção da aplicação é ter a possibilidade de escalabilidade, melhores meios de manutenção, gerenciamento de equipes, melhores métodos de reutilização, levam a necessidade de termos um sistema desacoplado em serviços.

Figura 3: Diferença entre estrutura monolítica e microsserviços

Fonte: Red Hat (2017)

A arquitetura de microsserviços tem como características de benefícios:

• Heterogenia: Podendo ser usado diferentes tecnologias dentro de cada serviço.
• Resiliencia: Caso um serviço do sistema pare, não afeta em outros serviços, mantendo a aplicação ainda funcionando sem aquele serviço.
• Escalabilidade: Por estar separado em contextos de serviços, dessa forma menores que uma aplicação monolítica, pode-se redimencionar apenas determinados serviços. Além de permitir que sejam executados em sistema com hardwares limitados a fazer apenas determinadas tarefas.
• Facilidade de implementação: Diferente do impacto a aplicação monolítica pode causar quando se espera alguma alteração de milhares de linhas de códigos, no microsserviço por ter contextos mais enxutos, assim tendo menores riscos na implantação.
• Alinhamento organizacional: Solucionando problemas de grandes números de membros trabalhando em um mesmo projeto, distribuindo-as em menores membros por grupos responsáveis por determinados serviços. Melhorando a produtividade.
• Reutilização de código: A reutilização de contextos de serviços permite que as funcionalidades possam ser consumidas de diferentes maneiras para diferentes propósitos.

Dando suporte na solução de problemas, a arquitetura de microsserviços oferece ao desenvolvedor de software modularidade, que auxilia nos testes, no desenvolvimento e na manutenção. A tendência para o futuro dos sistemas de software é tornarem cada vez mais complexos e sistemas grandiosos ou ambiciosos, sendo fundamental a utilização conceitos como a arquitetura de microsserviços.

4. COMMAND QUERY RESPONSIBILITY SEGREGATION (CQRS)

Muitas aplicações seguem a arquitetura baseada em um servidor que é responsável por fornecer métodos CRUD (Create Read Update Delete). O método CRUD faz o trabalho de persistência e consulta no banco de dados, sendo toda a intenção de interação com a base de informações obrigatoriamente trafegada pelo o mesmo ambiente. Mas conforme o contexto que está sendo trabalhado torna-se mais complexo, pois o modelo CRUD não corresponde da melhor forma a esse tipo de tarefa.

Figura 4: Método CRUD

Fonte: Martin Fowler (2011)

Através da imagem acima, pode ser notado que o modelo que recebe atualizações de uma interface com o usuário para persistência no banco de dados é o mesmo modelo que retorna as consultas. Mas dependendo da complexidade exigida pelo sistema, entre consultas e persistências, certamente o modelo CRUD não atenderá da melhor forma a esse contexto. Nesse tipo de cenário eventualmente terão falhas como: lentidões, dificuldade de leitura do código, inconsistências, além de sobrecarregar o banco de dados que tem a tarefa de fazer ambas as operações, leitura e gravação.

O Command Query Responsability Segregation (CQRS), como o nome diz, tem a função de separar a responsabilidade de consulta e comando, e é exatamente o que esse padrão arquitetural faz. O CQRS é um padrão arquitetural criado por Greg Young e documentado no “CQRS Documents” de 2010. Porém, não tem como deixar de lado as contribuições feitas por Udi Dahan e Martin Fowler para o padrão. A ideia de CQRS é uma derivação de outro padrão, o Command Query Separation (CQS), criado por Bertrand Mayer durante a criação da linguagem de programação Eifell em 1985, e descrito em seu livro “Object Oriented Software Construction” de 1988.

CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation: a command is any method that mutates state and a query is any method that returns a value) (CODEBETTER, 2016).

Contudo, geralmente as aplicações de sistema fazem mais leitura do que criam inserções no bando de dados. No CQRS, por exemplo, por ter a separações lógicas desse processos como fundamentação do padrão, dessa forma otimizando as funções de entrada e saída. Tanto a entrada e saída de informações na base de dados ganham ao aplicar CQRS, visto que ao lidar com as consultas e modificações (comando) individualmente, a tarefa de leitura pode ser configurada possuindo apenas o necessário para que possa retornar alguma informação do banco de dados. Essa e outras vantagens serão mais exploradas na seção que define o coneito de “Queries”. Dessa forma, Udi Dahan (2009, p. 01), enfatiza dois princípios essenciais sobre CQRS que o desenvolvedor precisa compreender, sendo um a “collaboration” e o outro “Staleness”.

Collaboration refers to circumstances under which multiple actors will be using/modifying the same set of data – whether or not the intention of the actors is actually to collaborate with each other. There are often rules which indicate which user can perform which kind of modification and modifications that may have been acceptable in one case may not be acceptable in others. We’ll give some examples shortly. Actors can be human like normal users, or automated like software. Staleness refers to the fact that in a collaborative environment, once data has been shown to a user that same data may have been changed by another actor – it is stale. Almost any system which makes use of a cache is serving stale data – often for performance reasons. What this means is that we cannot entirely trust our users decisions, as they could have been made based on out-of-date information (DAHAN, 2009).

A arquitetura padrão em camadas não lida diretamente com nenhum dos dois problemas citados. Separar a lógica dos processos na aplicação sem desassociar o bando de dados entre leitura e escrita não é o máximo de otimização que o padrão CQRS pode oferecer como solução para os problemas apresentados por Dahan (2009).

Figura 5: Estrutura CQRS

Fonte: Fowler (2011)

Alguns profissionais de software podem achar que a complexidade adicionada ao ter que trabalhar com duas lógicas de processos, como é proposto em CQRS, supera os benefícios da utilização do padrão. Igualmente a outros padrões, o nível de complexidade que é colocado ao utilizar CQRS dependerá apenas de quem está aplicando o padrão, pois o conceito de CQRS não dita o quanto do CQRS tem que ser aplicado em um projeto, podendo se adaptar da melhor maneira a necessidade com o que está sendo trabalhado naquele momento. Entretanto, as aplicações atualmente estão disponíveis a milhares de usuários, com funções complexas e dados valiosos, exigindo uma alta quantidade de operações, entre consultas e modificações. É nesse tipo de sistemas que utilizam a arquitetura em camadas que podem ocorrer falhas graves como lentidão por uma sobrecarga no banco de dados, perda da disponibilidade dos dados, além de inibir uma consulta em vários serviços em uma arquitetura de microsserviços (Richardson, 2019). Portanto, o grau em que se aplica o padrão CQRS deve ser bem estabelecido à necessidade envolvida em um projeto.

5. Queries (Consultas)

A principal característica do padrão CQRS é a forma que o desenvolvedor passa a enxergar de maneira lógica os processos envolvidos no projeto. O entendimento do processo de consulta (Query) começa com uma pergunta: Justifica passar uma consulta ao banco de dados pelo mesmo caminho complexo que faz a inserção? Uma consulta a base de dados é uma tarefa simples, passando algo que identifique o que procura e retornando o resultado ao usuário, sem regras de negócio, pois não há necessidade de transformar requerimentos em padrões DTO (Objeto de Transferência de Dados).

Figura 6: Esquema CQRS

Fonte: Exploring CQRS and Event Sourcing (2012)

Apesar de não estarmos lidando com regras fixas como dito anteriormente, quando estamos trabalhando com CQRS é bastante aconselhável que a separação da lógica de processos reflita em uma separação dos bancos de dados igualmente. E uma melhor opção para o banco de dados que irá atender o processo de consulta seria o uso de um banco de dados desnormalizado (Fossmo, 2009). O benefício na otimização por ter a capacidade de retornar ao usuário apenas um modelo da tabela contendo toda a informação necessária, sem a necessidade de criarmos combinações com base na relação existente entre as tabelas, como reitera Dahan (2009): Código simples é código rápido.

6. Commands (Comandos ou Modificações)

Toda coleta de dados feita por uma aplicação que utilize CQRS, criando atualizações no bando de dados, é encaminhada pela interface de usuário para a via de comando, que fará a modificação no estado atual da tabela no bando de dados. Essa ordem feita pelo usuário é executada através de comandos, é conduzida até o modelo de domínio, que possui regras de negócio a serem validadas ou não. Como dito anteriormente, essa via possui boa parte da complexidade encontrada em CQRS, principalmente se adequarmos os modelos que melhores sem encaixam no padrão, como fila e evento.

Figura 7: Comparação entre o caminho de comando e de consulta

Fonte: Kanasz Robert (2013)

Conforme visto na imagem acima, a estrutura de comando envolve mais subtarefas, principalmente quando queremos ter um melhor gerenciamento possível desse processo. O processo pode ser explicado da seguinte forma:

1. UI - Uma interface de usuário entra com um pedido de modificação (Fazer pedido).
2. APPLICATION - O pedido é processador por um protocolo de comunicação, exemplo um HTTP.
3. COMANDO – Um comando é declarado conforme a expectativa, exemplo Criar Pedido, e coloca-o enfileirando em uma FILA
4. DOMÍNIO – Entra nas regras de negócio, verificando se todas as validações de um novo pedido foram obtidas com sucesso ou não. Caso o pedido tenha sucesso, o novo pedido é gravado no banco de dados, e então acontece um EVENTO informando ao usuário. E ao mesmo tempo disparando um evento que entra em uma nova FILA para então alertar através de algum componente que atualize o bando de dados desnormalizado.

7. Tipos de sincronização

Existem algumas estratégias para manter as bases de leitura e gravação sincronizadas, é necessário escolher a que melhor atende ao cenário do trabalho:

• Síncrona – Toda alteração de estado de um dado no banco de dados de gravação dispara um processo síncrono para atualização no banco de dados de leitura. Porém, para muito desenvolvedores esse é um tipo de sincronismo falho quando buscamos ter qualidades bem visíveis do padrão CQRS.
• Assíncrona – Toda alteração de estado de um dado no banco de dados de gravação dispara um processo assíncrono para atualização no banco de leitura oferecendo uma consistência eventual dos dados.

Figura 8: Tipos de sincronizações

Fonte: Microsoft (2018)

8. Event Sourcing

O Event Sourcing é um padrão que garante que todas as alterações no estado da aplicação sejam armazenadas como uma sequência de eventos, de acordo com a imagem (Figura 7). Tornando o banco de dados um armazém de processos, mantendo todos os registros de alterações feitas persistida na base de dados, permitindo um melhor controle dos dados. Fowler (2005) faz uma comparação com o mundo real para referenciar a importância de guardarmos o estado anterior de um dado, ele diz “We can query an application’s state to find out the current state of world, and this answers many questions. However there are times when we don’t just want to see where we are, we also want to know how we got there”. O primeiro relator do padrão foi feito por Fowler em 2005, gerando outros trabalhos excelentes sobre essa abordagem de outros especialistas de software, como o próprio Greg Young (2010), criador do termo CQRS.

Considerando os atuais modelos de negócio que utilizam banco de dados da maneira tradicional, onde apenas o último estado de uma entidade é mantido na base de dados, e os dados anteriores são sobrescritos. De acordo com Fowler (2005), ao trabalhar com Event Sourcing a aplicação passa a ter um histórico de eventos que facilmente podem ser reconstruídos. E por aceitar apenas as inclusões de novos eventos, isso garante um ótimo desempenho para a aplicação. Além disso, ter conhecimento sobre a natureza dos eventos leva o desenvolvedor a dar mais importância ao comportamento das entidades de domínio.  Desse modo, a abordagem de Event Sourcing entrega um padrão muito eficaz de comunicação com o resto da aplicação, cuja conversação acontece sobre API’s de forma atômica, sendo um novo evento anexado a sequência de eventos em um armazém de processos.

9. O conceito de CQRS e Event Sourcing em microsserviços

Para auxiliar o desenvolvimento de uma aplicação que utilize o estilo arquitetural de microsserviços, foi empregado um método dando a essa abordagem complementos necessários para que não haja desvio sobre conceitos de desacoplamento modular. E assim garantir a dependência de cada serviço juntamente aos bancos de dados dedicados, mantendo coesão e a disponibilidade dos dados entre a utilização e troca de informação entre diferentes serviços. Sem que ocorram erros inesperados por falhas, tanto como atrasos por deadlocks ou dados inexistentes, proponho uma solução bastante eficiente, que é a integração dos padrões CQRS e Event Sourcing na arquitetura de microsserviços.

O esquema proposto funcionará com o CQRS como um separador das intenções dos serviços, com base específica no banco de dados. Assim sendo, atuando como uma camada de comandos para persistências, contendo seus comandos de modificações, e outra apenas para consultas. Portanto, mantendo a separação lógica dos bancos de dados igualmente dos serviços, de forma assíncrona. Logo, foi criado um diagrama para que possa ser visualizado todas as comunicações através de mensagens de serviços, mostrando a interação com os bancos de dados próprio e de outros serviços.

Figura 9: Microsserviços com padrões CQRS e Event Sourcing

Fonte: Fabrício Ramos (2019)

Desse modo, o microsserviço recebe um requerimento feito por um usuário através de uma API, que deve ser mantido de forma síncrona com um HTTP. Dependendo da interação, o processo poderá seguir pelo caminho de consulta ou de comando. A consulta como pode ser visto no diagrama acima, é feita ao banco de dados desnormalizado por um NoSQL para apenas leitura. Esses bancos de dados de leitura se atualizam através de eventos gerados automaticamente por um sistema assíncrono de mensagem, responsável por toda a comunicação de modificação no estado ou pedido de consulta entre os diferentes microsserviço. As mensagens são armazenadas em um sistema de filas até serem liberadas por um único evento que a consume. Essas mensagens são reconhecidas por um cabeçalho identificador, passando o contexto da mensagem. Dessa forma, as mensagens são enviadas utilizando um protocolo de enfileiramento de mensagem assíncrono, como um AMPQ (Advanced Message Protocal Queue) ou em um contexto mais complexo de sistema em nuvem, como por exemplo, o Microsoft Azure Service Bus Queue.

No ponto de vista de gravação no armazenamento de eventos, sua responsabilidade é gerenciada pelo caminho de comando. Toda a atualização será escrita e salva em um armazenamento de eventos e ao mesmo tempo publicando uma notificação de evento para o sistema de mensagem. Caso a mensagem atenda todas as regras de negócio da aplicação, retornará uma mensagem positiva para a API e interface de usuário, caso contrário, o usuário receberá uma notificação de falha na ação. Quando a gravação é positiva, um evento é disparado através da mensagem e o banco de dados de leitura é atualizado. Essa ideia de trabalhar com armazenamento e eventos vem do Event Sourcing, cujo CQRS utiliza evento, porém sem persisti-lo.

A complexidade que é gerada ao utilizar CQRS e Event Sourcing em um sistema em microsserviços deve atingir apenas as necessidades da aplicação. Entretanto, quando utilizamos esses padrões em uma arquitetura de microsserviços, é muito provável que o nível de complexidade com o qual estará trabalhando tenha a necessidade de manter as melhores práticas do uso, tal qual foram descritas acima. Quando usamos os padrões CQRS e Event Sourcing nesse tipo de ambiente e nesse contexto, os benefícios são dos mais variados, que recompensa o trabalho extra que o desenvolvedor terá.

10. Conclusão

Com base nos estudos e uso do padrão CQRS e Event Sourcing, conclui-se que a arquitetura de microsserviços tem a capacidade de alcançar sua plena função em contextos complexos de sistemas. Transformando um sistema frágil de microsserviços, com falhas inerentes, em um sistema robusto que contribui para uma otimização em diversos aspectos, como:

• Um melhor aproveitamento da modularização dos microsserviços, como os bancos de dados devidamente únicos a cada serviço;
• Melhor gerenciamento da comunicação através de eventos automáticos, garantindo a integridade dos dados;
• Manter todo o histórico persistido para a análise e comparativos com outros dados;
• Redução de sobrecarga no banco de dados pela distribuição das operações de consulta e modificação;
• As leituras nos bancos de dados podem ser concluídas mais rapidamente graças à nova configuração.

No entendo, o custo e o beneficio do uso dessas abordagens devem ser bem planejadas, atendendo o caso especifico DE projeto a ser trabalho. A relevância do tema para esse trabalho foi gerada a partir de uma aplicação utilizando as tecnologias e linguagem de programação da plataforma.NET, como por exemplo C#, ASP.NET Core, MediatoR, AutoMapper, Service e Repository Pattern, EntityFramework, MongoDB e conceitos de modelagem Domain-Driven Design.

Portanto, o uso dos padrões CQRS e Event Sourcing em arquitetura de microsserviços permite aos profissionais de software soculionar com sucesso os requerimentos exigidos a uma aplicação moderna.

11. Referências

BETTS, Dominic, et al. Exploring CQRS and Evento Sourcing. Microsoft, 2013. Disponí-vel em: < https://www.microsoft.com/en-us/download/details.aspx?id=34774 >. Acessado em: 21 junho 2019.

DAHAN, Udi. Clarified CQRS. udidahan, 2009. Disponível em: . Acessado em: 20 junho 2019.

EVANS, Eric. Domain-Driven Design, 3º.ed. Rio de Janeiro: Alta Books, 2016.

FOWLER, Martin. Event Sourcing. 2005. Martinfowler. Disponpivel em: . Acesso em: 10 julho 2019.

FOWLER, Martin. CQRS, 2011. Disponível em: < https://martinfowler.com/bliki/CQRS.html >. Acessado em: 09 julho 2019.

YOUNG, Greg. CQRS Documents. CQRS, 2010. Disponível em: . Acesso em: 13 de agosto de 2019.

MEYER, Bertrand. Object Oriented Software Construction, 2º.ed. New Jersey: Prentice
Hall, 1997.

RICHARDSON, Chris. Microservices Pattern, 1º.ed. 2019. Nova York: Manning Publica-tions, 2019.

NEWMAN, Sam. Building Microservices, 1º.ed. Massachusetts: O’Reilly Media, 2015.