Eventos de domínio e notificações não são a mesma coisa

A maioria dos sistemas 'orientados a eventos' que audito não é orientada a eventos. É orientada a notificações com um barramento de eventos no meio. A diferença parece acadêmica até você tentar adicionar um segundo consumidor, reprocessar o histórico ou explicar a um gerente de produto por que a contagem de pedidos em dois dashboards não bate.

Um evento de domínio é um fato: algo aconteceu no negócio, tem nome no passado, e carrega informação suficiente para que um estranho entenda o que mudou. PedidoPago, com id do pedido, valor, moeda, forma de pagamento e timestamp. Uma notificação é um cutucão: 'algo no pedido 4471 mudou, vai olhar'. Carrega um id e talvez um tipo, e espera que o consumidor chame de volta para buscar o estado.

Os dois são legítimos. Resolvem problemas diferentes, e todo sistema confuso que já vi escolheu um enquanto precisava do outro.

O que um evento de domínio promete

Um evento de domínio promete três coisas. É imutável, porque descreve o passado. É autocontido, então um consumidor pode agir sobre ele sem chamar o produtor de volta. E tem significado na linguagem do negócio, não na linguagem do banco. 'EndereçoDoClienteAlterado' é um evento de domínio. 'linha da tabela customers atualizada' não é, mesmo que viaje pelo mesmo broker.

Essas promessas tornam eventos de domínio poderosos. Você pode reprocessá-los para reconstruir um read model. Pode adicionar um consumidor um ano depois e ele vai entender o histórico. Pode auditar o que aconteceu sem cruzar logs de três serviços. Analytics, notificações, checagem de fraude, expedição: cada um assina e faz o seu, e o produtor nunca fica sabendo que eles existem.

O custo é que o produtor precisa decidir, na hora de emitir, o que vale a pena registrar. O payload é um contrato. Mude sem cuidado e todo consumidor que interpretava a forma antiga quebra, às vezes em silêncio, meses depois, quando um reprocessamento encontra uma versão velha.

O que uma notificação promete

Uma notificação promete quase nada, e essa é sua força. Ela diz 'vai conferir'. O consumidor chama a API do produtor e recebe o estado atual, então sempre vê a verdade de agora, não a de quando o evento saiu. Não há contrato de payload para manter além do id. O produtor pode mudar seu modelo interno à vontade.

O custo é acoplamento na direção contrária. O consumidor depende de o produtor estar disponível e rápido quando a notificação chega. Dez consumidores significam dez chamadas de volta por mudança. Reprocessar notificações não serve para nada, porque o estado que elas apontam já se moveu. E não existe histórico: você sabe que o pedido 4471 mudou doze vezes, mas não o que mudou em cada uma.

Onde a confusão causa estrago

A falha mais comum é emitir notificações e tratá-las como eventos. Um time publica 'PedidoAtualizado' só com um id. Aí alguém constrói um read model consumindo isso e buscando o pedido. Aí outra pessoa adiciona uma checagem de fraude no mesmo tópico. Aí a API de pedidos tem uma tarde ruim e as chamadas de todos os consumidores falham, o read model diverge, a checagem de fraude perde uma janela e ninguém consegue reconstruir nada, porque o tópico não contém fatos, só ponteiros para um estado que já mudou.

A falha oposta é mais silenciosa. Um time emite eventos de domínio ricos, e um consumidor ignora o payload e chama a API mesmo assim 'por segurança'. Agora você paga o custo dos dois: um contrato de payload para manter e uma dependência síncrona do produtor. O barramento de eventos vira um jeito muito caro de disparar chamadas HTTP.

A terceira falha é de nome. 'PedidoAlterado' não é evento de domínio, porque o negócio não pensa em 'alterado'. Pensa em feito, pago, embalado, enviado, estornado. Se o nome de um evento não apareceria numa conversa entre duas pessoas que trabalham naquele domínio, é uma notificação técnica fantasiada de domínio.

Como eu decido

Pergunto o que o consumidor vai fazer. Se precisa reagir a um fato de negócio específico e deve continuar funcionando com o produtor fora do ar, precisa de um evento de domínio com payload de verdade. Se só precisa atualizar um cache ou uma tela e não tem problema buscar o estado mais recente, uma notificação é mais barata e mais segura, porque não há contrato para evoluir.

Depois pergunto sobre histórico. Se alguém um dia vai querer saber o que aconteceu, em ordem, com detalhes, só eventos de domínio entregam isso. Se ninguém vai, não pague por isso.

E dou nomes honestos. Fatos no passado, com o vocabulário de quem toca o negócio. Cutucões como cutucões: 'AtualizaçãoDePedidoSolicitada', com um id, sem fingimento. Um sistema em que os dois são visivelmente diferentes é um sistema em que um engenheiro novo consegue dizer, só pelo nome, em que ele pode confiar.