.png){kind=small}
.png){kind=small}
Quando trabalhamos com qualquer arquitetura, temos alguns padrões. Com Event Driven Arquitetura, não é diferente. Por isso, temos 3 padrões principais, que são: Notificação de Evento, Transferência do Estado Transportado pelo Evento e Fonte do Evento. Que tal saber um pouco mais sobre eles?
Quando trabalhamos com Notificações de Eventos, o sistema enviará notificações a outros sistemas sobre uma mudança ocorrida em seu domínio, caso algum dos sistemas que recebem a notificação esteja interessado em saber mais sobre a mudança, ela deverá ir para uma interface fornecida pelo provedor para capturar mais informações.
Ainda vamos usar o exemplo do artigo anterior (se você ainda não o leu, ainda está a tempo, pois está disponível neste link), que é uma mudança de endereço do cliente, mas agora, pense em mim em um caso hipotético de mercado (que pode ser real; aceito royalties), um mercado de vendas vai compartilhar seus dados mestres de clientes com parceiros de mercado, incluindo bancos. Isto será especialmente útil para atualizações relacionadas a informações de endereço, pois é mais fácil para mim atualizar meu endereço em um mercado onde obterei o novo produto que comprei, em vez de lembrar de atualizar o banco. Com este exemplo em mente, vamos ao nosso caso de uso usando a Notificação de Evento.
Os clientes mudarão seu endereço, os Centros de Serviço ao Cliente serão responsáveis por atualizar as informações no banco de dados e acionar uma notificação de evento com a mensagem "Cliente 43F31A1 dados atualizados" para seu corretor, os centros de serviço que visam informações daquele sistema estarão escutando e se, por exemplo, o serviço bancário reconhecer o cliente e estiver interessado em seus dados atualizados, eles farão uma chamada para os centros de serviço ao cliente tais como GET/customers/43F31A1 para recuperar as informações e atualizar seus dados. Se o serviço bancário não conhece os clientes em questão, ele simplesmente ignorará a mensagem. Ao utilizar este padrão, temos a vantagem de um acoplamento baixo, pois separamos o receptor do remetente e como desvantagem podemos ter as despesas gerais do produtor, pois pode haver N sistemas que estão interessados na atualização e, ao mesmo tempo, podem procurar mais informações sobre o mesmo com o produtor.
Usaremos a Transferência de Estado Transportada pelo Evento quando tivermos que enviar as informações completas na mensagem, para que os processadores não precisem consultar um produtor para descobrir quais foram as mudanças.
Em nosso exemplo, os clientes mudarão seu endereço e o Centro de Atendimento ao Cliente será responsável por atualizar as informações no banco de dados e acionar uma notificação de evento, mas ao invés de apenas dizer que o cliente 43F31A1 atualizou os dados, ele enviará a mensagem com dados completos; como no caso da mudança do código postal, a mensagem deverá ser "Cliente 43F31A1 atualizou o código postal para 29580000", e com isso, os processadores terão as informações completas para realizar seu trabalho. O processador pode armazenar as informações em um banco de dados local, de modo que, ao realizar o processamento posterior, não precisa se referir às informações com o produtor, que, em nosso caso, é o centro de atendimento ao cliente.
Ao utilizar este padrão, ganhamos resiliência, já que os processadores poderão funcionar mesmo que o produtor não esteja disponível. Também reduziremos a latência, pois não teremos mais que ir ao produtor para obter mais informações, e como você já deve ter notado, uma das vantagens é que também não sobrecarregaremos mais o sistema do produtor, pois a mensagem contém todas as informações necessárias.
Os contras incluem a replicação de informações e o fato de que o processador deve estar preocupado com a consistência dos dados, uma vez que agora ele também possui informações.
Usamos Event Source quando precisamos armazenar as mudanças que ocorrem no estado de um sistema. Com cada mudança, armazenaremos a modificação como um evento e, quando necessário, será possível reconstruir o estado do sistema com confiança, reprocessando assim os eventos.
Conforme nosso exemplo, o cliente mudará seu endereço e o Centro de Atendimento ao Cliente será responsável por atualizar as informações no banco de dados e enviar o evento de mudança de endereço, que será armazenado junto com os dados alterados, em um repositório ou banco de dados. Se a qualquer momento nosso atendimento ao cliente for excluído, por exemplo, teremos uma Fonte de Dados de Eventos que nos permitirá reconstruí-la, para que ela possa permanecer como estava antes.
Ao utilizar a Event Source, ganhamos a auditoria. Se eu quiser saber o que aconteceu e quando ocorreu, posso consultar meu repositório e descobri-lo. Também nos beneficiamos de poder depurá-lo, o que é um ponto complicado quando estamos trabalhando com a orientação de eventos. Se for necessário depurar o sistema, pode-se apontar o ambiente de teste para o repositório e realizar todas as validações que forem necessárias.
Como desvantagens podemos mencionar que a Event Source ainda não é amplamente utilizada no mercado, o que pode tornar difícil encontrar materiais que abordem o assunto.
Além disso, temos também o Esquema de Eventos, que diz respeito ao que vamos armazenar no repositório. Todos os eventos ocorrerão ou somente os próximos eventos ocorrerão? Precisamos escolher corretamente o esquema que iremos seguir ao armazenar as informações.
Bem, estes são 3 dos padrões que temos na arquitetura orientada a eventos. Você já trabalhou com algum deles? Como foi sua experiência? Informe-nos! E fique atento. Em breve publicaremos um artigo abordando a documentação das interfaces assíncronas, a saber, AsycAPI.
