Elaborando projetos com a Arquitetura Orientada a Eventos

Uma das maneiras de tentar estabelecer uma comunicação organizada e controlada entre os componentes que formam o conjunto de sistemas de uma empresa/departamento seria utilizar a ocorrência de um fato, ou seja, um evento, pois desta forma teríamos a comunicação entre as partes mantida com um baixo acoplamento, onde emissores e assinantes estariam ligados apenas pela criação destes eventos.

Além dos eventos definirem o momento em que a integração pode ocorrer, possuem as informações necessárias que serão trocadas entre as peças, efetivando as integrações.

No acontecimento de um evento, ações podem ser tomadas pelos interessados sem a necessidade de qualquer tipo de atuação por parte do gerador do evento.

Mas dentro do nosso contexto de tecnologia: o que são estes eventos? A resposta é: depende! Apesar de a resposta parecer uma tentativa de ludibriar alguém que você gostaria de convencer, ela realmente depende do contexto envolvido, ou seja, do modelo do domínio de negócio que estamos nos referindo.

O evento é algo relevante para o negócio da empresa, podendo ser: a ocorrência de uma venda, o cadastro de um novo cliente, a desistência de uma assinatura de revista, saques em locais geograficamente distantes do mesmo correntista, ou o valor acumulado de pedidos realizados dentro de um período.

A definição do que pode ser considerado um evento está muito mais orientada ao negócio da empresa do que a decisões técnicas. É claro que é possível também estabelecer eventos de natureza técnica como, por exemplo: o tempo médio da execução de transações ou a quantidade de execuções de um serviço no mês.

Porém, na maioria dos cenários, ao estabelecer uma arquitetura orientada a eventos, a prioridade fica para a definição e captura de eventos do negócio em questão, para que a empresa tenha mais benefícios sobre o orçamento investido em tecnologia.

Os eventos de natureza técnica (como tempo de resposta) ganham maior prioridade quando afetam diretamente os negócios da empresa.

Em uma arquitetura orientada a eventos, colocamos obviamente como ator principal o evento, estabelecendo assim o elo que causará a integração entre os sistemas e componentes. Vale ressaltar ainda que um evento é autocontido, isto é, carrega consigo a informação de quando está preparado para ser disparado e quais informações deve conter.

O que de fato a Arquitetura Orientada a Eventos (EDA – Event Driven Architecture) deve promover é uma estrutura que possa estabelecer o alicerce de apoio à integração entre os sistemas e/ou componentes do ambiente – usufruindo da ocorrência de evento –, de forma que ainda se mantenha um baixo acoplamento entre os participantes.

Obviamente, assim como a definição de um modelo de domínio para a criação de uma aplicação, a modelagem de quais eventos serão tratados deve fazer parte da análise da solução.

Principalmente porque estes eventos serão utilizados por vários sistemas distintos da corporação, o que sugere colocá-los como parte do modelo canônico, junto com as entidades de negócio e mensagens comuns utilizadas pelos diferentes sistemas da empresa.

Dentro do ambiente de uma empresa com vários sistemas distintos, existem potenciais emissores e assinantes destes eventos. Neste cenário, os emissores de eventos possuem as informações e o contexto associado ao disparo, fazendo o evento existir de forma consistente e válida para consumo por todos os interessados.

A complexidade para a definição de uma estrutura que possa auxiliar o controle e organização entre emissores e assinantes de eventos, estabelecendo uma Arquitetura Orientada a Eventos, vai depender da maturidade de integração existente na empresa.

É nesse momento que a adoção e estabelecimento de uma Arquitetura Orientada a Serviços mostra suas vantagens. Ao temos um mediador responsável por tratar as integrações, que centraliza os serviços existentes no ambiente, criar uma arquitetura para eventos se torna mais fácil.

Pelo barramento de serviços podemos identificar os serviços expostos de ...