BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Experiências na construção de uma Aplicação Reativa com CQRS e Dirigida por Eventos

Experiências na construção de uma Aplicação Reativa com CQRS e Dirigida por Eventos

Favoritos

Ser reativo por design e possuir um modelo de domínio imutável foram requisitos importantes para a arquitetura descrita por Duncan DeVore em sua recente apresentação no Scala Days 2014. No evento realizado em Berlin, Duncan compartilhou suas experiências obtidas na construção de uma aplicação distribuída baseada nos padrões CQRS e Event Sourcing, com consistência de eventos e escrita com Akka e Scala.

Vice Presidente de Engenharia de uma Companhia de Energia, Duncan descreve o padrão CQRS (Separação de Responsabilidades de Comando e Consulta) como sendo a separação de comandos e consultas em dois objetos, permitindo otimização isolada de cada componente. Segundo Duncan, esta é uma necessidade recorrente em diversas arquiteturas atuais.

No CQRS, apesar de os comandos mudarem estado, eles estão mais relacionados com alteração de comportamento do que com alteração de dados: uma requisição para efetuar uma tarefa ou ação, de preferência transferida na forma de mensagem. Já consultas formam uma fina camada de leitura acima do armazenamento de dados, não sendo uma projeção direta do modelo de domínio. Ao invés disso os dados são armazenados com uma chave única permitindo que dados correlacionados (mesma tela ou fetch) sejam lidos em uma única consulta.

Um desafio para a separação da escrita e leitura trata-se da consistência eventual, pois é necessário um tempo entre escrita e leitura para que os dados estejam consistentes.

Atualmente, a maioria das aplicações confiam no armazenamento do estado atual e Duncan acredita que este fato é um efeito colateral da adoção de sistemas de banco de dados relacionais (RDBMS). Em contraste, o padrão Event Sourcing consiste em capturar eventos, sendo o sistema comportamental por natureza, de forma a não persistir o estado atual. Este estado na verdade é derivado dos eventos capturados.

Um exemplo onde a utilização deste padrão se apresenta como uma vantagem, são situações onde, por exemplo, exista um requisito para listar todas as transações nas quais os clientes removeram itens em um carrinho de compras existente. Para um sistema que armazene o estado atual, isso só pode ser aplicado para novas transações. Para um sistema baseado em eventos, os eventos pertinentes as transações já estão armazenados, sendo necessário somente adicionar a funcionalidade de relatório dos eventos armazenados.

Em modelos de negócio maduros a noção de rastreabilidade é muito comum. Um exemplo são contas bancárias onde todas as transações, como depósitos e saques, são gravadas. O estado atual pode ser confiável desde que este seja recriado através da re-execução de todas as transações anteriores.

Ducan ressalta duas implicações tecnológicas quando se está trabalhando com eventos. O sistema de armazenamento torna-se somente um complemento para a arquitetura, de forma a facilitar sua distribuição e o particionamento horizontal se torna fácil já que uma chave única é utilizada para recuperação de dados.

Duncan ainda afirma:

Acredito que a combinação dos padrões CQRS e Event Sourcing, forneça um modo limpo e conciso para construir aplicativos distribuídas aderentes ao manifesto reativo.

O Manifesto Reativo foi publicado em Setembro de 2013, e Duncan é coautor do livro intitulado "Building Reactive Applications" (Construindo Aplicações Reativas), que será lançado em breve.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT