Sempre que somos tocados por algum tipo de desenho ou arquitetura que demonstra significativo ganho em um determinado cenário, tendemos a tentar reaproveitar esse mesmo desenho mais pela memória do sucesso passado, do que pela necessidade efetivamente. Aqui está uma casca de banana, e é sobre isso que vamos discutir hoje.

A proposta do EDA

Event Driven Architecture visa organizar a forma como os fluxos de negócio acontecem em um sistema, privilegiando o desacoplamento usando eventos para notificar outras partes do software em detrimento de chamadas diretas com alto acoplamento. O reflexo desse desenho é a fragmentação de atividades que antes faziam parte de um transaction script ou pipeline e agora estão distribuídos em eventos e handlers e comandos e workers.

Nessa arquitetura emerge a categorização forte que diferencia mensagens em 2 categorias: Eventos e Comandos.

Leia “EDA – Event Driven Architecture: Não confunda eventos com comandos“

Um evento notifica que algo aconteceu, enquanto um comando consiste na solicitação de execução de uma atividade.

Entendendo Event Driven

Mas vamos entender Event Driven para que fique mais claro.

Vamos supor que você tenha o cadastro de pedidos, como na Imagem 1. Nesse cadastro você executa um insert em um banco de dados e realiza mais 4 tarefas: Enviar email, Realizar pagamento, Emissão de Nota e Envio do pedido para o ERP.

Note que cadastrar pedido precisa conhecer todos os requisitos desses 4 serviços:

• Envio de Email
• Pagamento
• Notas
• ERP

é aqui que está o acoplamento e a complexidade adicional que Event Driven se presta a solucionar, fragmentando essa complexidade em componentes independentes.

Embora do ponto de vista de negócio faça sentido que essas tarefas sejam realizadas, a discussão ocorre sobre quem, quando e como realizar essas tarefas.

O objetivo da proposição é reduzir acoplamento para que Cadastrar Pedido só cadastre o pedido. O resto tem de acontecer, mas Cadastrar Pedido não precisa tomar ciência, não é responsabilidade nem competência desse serviço. Aqui estamos falando de simplificar e reduzir.

O primeiro esforço em tornar esse processamento mais isolado, em geral produz um resultado parecido com o que vemos na Imagem 2.

Embora tenhamos um isolamento entre os processos, e podemos escalar individualmente cada um dos 4 serviços, continuamos com o acoplamento alto no cadastro de pedidos.

Event Driven enxerga esse problema de uma forma muito diferente. A imagem 3 torna mais claro como ficaria essa solução.

Cadastrar Pedido agora, faz o insert no banco, e sua única outra responsabilidade é notificar, via mensageria, que um pedido foi cadastrado. O Cadastro de Pedidos, sequer sabe quem são os interessados, nem quais operações serão realizadas depois.

Por outro lado embora o código não esteja mais junto com o Cadastrar Pedido, ele precisa estar em algum lugar. E é aí que entram os handlers. Os handlers são tratadores de eventos. Eles recebem um evento, e transformam em novos comandos para poder prosseguir com o fluxo.

Aqui tem uma série de padrões e questões específicas, como a demanda do handler por obter mais informações, que geralmente demanda consultas HTTP (obviamente não resilientes). Isso é um tema bem denso, porque enquanto está no mundo abstrato das ideias você não consegue enxergar muita coisa, inclusive que a resiliência desse handler é assegurada pela infraestrutura assíncrona que o ativou.

O que quero trazer é que essa relação [Comando▶️Worker▶️Evento▶️Handler▶️Comando] é natural.

Legenda:

As vantages desse desenho sem sombra de dúvidas são: a flexibilidade e o baixo acoplamento, no entanto é notório que é um desenho bem mais complexo.

Não há questionamento quanto à eficiência e eficácia de EDA. As questões que existem são sobre a necessidade e a complexidade que vem à reboque.

Se quiser saber mais sobre Event Driven Architecture, deixe nos comentários.

Mas fica uma questão: Quando usar? Quando não usar?

No RabbitMQ para Aplicações .NET, eu tendo direcionar o pessoal a usar EDA quando claramente você tem cenários de vários eventos.

A relação de [Comando▶️Worker] é típica de qualquer adoção de mensageria, inclusive EDA.

Assim nos resta saber se precisamos do fluxo [Worker ▶️ Evento ▶️ Handler ▶️ Comando ▶️ Worker]. Essa é a parte crítica desse processo de tomada de decisão.

Por padrão eu tendo a ser mais conservador, evitando essa complexidade até que a necessidade se torne óbvia. Claro que exige um certo nível de atenção. Mas eu tendo a começar de forma direta e mais acoplada até que eu enxergue oportunidade de desacoplamento.

O acoplamento nesse caso, não é acidental, ele é um ponto de atenção. Com a evolução do projeto, as demandas emergem e com elas temos clareza sobre os pontos críticos. Geralmente onde você precisava enviar 1 única mensagem no passado, ao chegar uma nova demanda, precisará enviar a 2ª, depois 3ª… esses são os primeiros casos elegíveis.

A partir da 2ª mensagem (um worker precisando enviar 2 mensagens) já é saudável avaliar a adoção de eventos.

Então eu começo usando apenas [Comando▶️Worker], de forma simples, básica, direto ao ponto, até que consiga encontrar cenários onde o worker está (ou perceptivelmente vai ficar) gordo e complexo.

Nesse momento a decisão óbvia é partir para a produção de eventos e criação de handlers.

E também tem os casos clássicos em que já é possível começar pensando em EDA desde a concepção, são os cenários óbvios onde você sabe que quer plugar handlers posteriormente e sabe que são pontos de evolução do projeto. O Cadastro de Pedidos é esse típico cenário.

A gente se vê no próximo post.