Desacoplando Notificações de Leads com o Observer Pattern em Java

Davi Sousa Oliveira — Thu, 10 Sep 2026 22:46:51 +0000

Introdução

O Observer Pattern (Padrão Observador) é um padrão de projeto comportamental, ou seja, ele trata de como os objetos se comunicam e distribuem responsabilidades entre si em tempo de execução — diferente dos padrões criacionais (que tratam de como objetos são instanciados) ou estruturais (que tratam de como objetos se compõem).

A ideia central é simples: um objeto, chamado Subject (ou "Sujeito"), mantém uma lista de dependentes, chamados Observers, e os notifica automaticamente sempre que seu estado muda — sem precisar saber quem são esses observadores ou o que cada um faz com a informação.

O Problema

Recentemente, ao trabalhar na captação de leads de uma landing page para uma incorporadora, esbarrei num cenário bem comum: assim que um lead preenche o formulário, várias coisas diferentes precisam acontecer ao mesmo tempo —

o lead precisa ser sincronizado com o CRM;
o time de vendas precisa ser avisado no WhatsApp ou Slack;
uma automação de e-mail de boas-vindas precisa ser disparada;
o evento precisa ser registrado para analytics.

A primeira versão "ingênua" desse fluxo costuma ficar assim: o método que captura o lead chama, um por um, cada um desses serviços diretamente.

public void capturarLead(Lead lead) {
    crmService.sincronizar(lead);
    whatsappService.notificarVendedor(lead);
    emailService.enviarBoasVindas(lead);
    analyticsService.registrarEvento(lead);
}

Isso funciona, mas cria um problema clássico de acoplamento forte: a classe responsável por capturar o lead passa a conhecer os detalhes de todos os serviços que reagem a esse evento. Toda vez que um novo canal de notificação entra (por exemplo, um novo webhook para um parceiro), é preciso alterar essa classe central — violando o Princípio Aberto/Fechado (open/closed principle): o código deveria estar aberto para extensão, mas fechado para modificação.

Conceito

O Observer resolve isso invertendo a responsabilidade: em vez do "emissor" saber quem precisa ser avisado, cada interessado se inscreve para receber avisos.

Uma analogia direta é a de um grupo de transmissão (broadcast list) de WhatsApp: quem envia a mensagem não precisa saber quem são os contatos do grupo, nem o que cada um vai fazer ao ler — só dispara a mensagem para a lista. Quem quiser deixar de receber, sai do grupo; quem quiser passar a receber, entra. O emissor nunca muda.

Estruturalmente, isso se traduz em duas abstrações:

Subject: mantém uma coleção de observers e expõe métodos para inscrever (subscribe), remover (unsubscribe) e notificar (notify) todos eles.
Observer: define um contrato único (geralmente um método update) que qualquer interessado precisa implementar para reagir ao evento.

O Subject nunca conhece as classes concretas dos observers — apenas a interface. Isso é o que permite adicionar ou remover reações ao evento sem tocar no código que dispara o evento.

Cenário do Mundo Real

Vamos aplicar isso exatamente ao cenário descrito: um serviço de captação de leads (LeadCaptureService) que atua como Subject, e quatro observadores desacoplados:

CrmSyncObserver — sincroniza o lead com o CRM via API;
SalesNotifierObserver — notifica o vendedor responsável via WhatsApp Business API;
WelcomeEmailObserver — dispara o e-mail de boas-vindas;
AnalyticsObserver — registra o evento para métricas de conversão.

Diagrama UML de Classes

Desenho de Arquitetura

O formulário da landing page dispara uma chamada para o backend, que atua como o Subject. A partir daí, o LeadCaptureService não sabe — nem precisa saber — que existem quatro reações diferentes acontecendo; ele só notifica sua lista de observers.

Implementação em Java

// Contrato do Observer
public interface LeadObserver {
    void update(Lead lead);
}

// Contrato do Subject
public interface LeadSubject {
    void subscribe(LeadObserver observer);
    void unsubscribe(LeadObserver observer);
    void notifyObservers(Lead lead);
}

// Subject concreto
public class LeadCaptureService implements LeadSubject {

    private final List<LeadObserver> observers = new ArrayList<>();

    @Override
    public void subscribe(LeadObserver observer) {
        observers.add(observer);
    }

    @Override
    public void unsubscribe(LeadObserver observer) {
        observers.remove(observer);
    }

    @Override
    public void notifyObservers(Lead lead) {
        for (LeadObserver observer : observers) {
            observer.update(lead);
        }
    }

    public void capturarLead(Lead lead) {
        // regra de negócio de captação (validação, persistência, etc.)
        salvarLead(lead);
        notifyObservers(lead);
    }

    private void salvarLead(Lead lead) {
        // persistência do lead
    }
}

// Observers concretos
public class CrmSyncObserver implements LeadObserver {
    @Override
    public void update(Lead lead) {
        // chamada à API do CRM
        System.out.println("Lead sincronizado com o CRM: " + lead.getNome());
    }
}

public class SalesNotifierObserver implements LeadObserver {
    @Override
    public void update(Lead lead) {
        // chamada à WhatsApp Business API
        System.out.println("Vendedor notificado sobre o lead: " + lead.getNome());
    }
}

public class WelcomeEmailObserver implements LeadObserver {
    @Override
    public void update(Lead lead) {
        // disparo de e-mail transacional
        System.out.println("E-mail de boas-vindas enviado para: " + lead.getEmail());
    }
}

public class AnalyticsObserver implements LeadObserver {
    @Override
    public void update(Lead lead) {
        // registro de evento de conversão
        System.out.println("Evento de conversão registrado para: " + lead.getNome());
    }
}

Registrando os observers e disparando o fluxo:

public class Main {
    public static void main(String[] args) {
        LeadCaptureService leadService = new LeadCaptureService();

        leadService.subscribe(new CrmSyncObserver());
        leadService.subscribe(new SalesNotifierObserver());
        leadService.subscribe(new WelcomeEmailObserver());
        leadService.subscribe(new AnalyticsObserver());

        Lead lead = new Lead("Maria Silva", "maria@email.com");
        leadService.capturarLead(lead);
    }
}

Note que, para adicionar um quinto canal — digamos, um webhook para um parceiro imobiliário — basta criar uma nova classe implementando LeadObserver e registrá-la com subscribe(). Nenhuma linha de LeadCaptureService precisa mudar.

Prós e Contras

Vantagens:

Baixo acoplamento: o Subject não conhece as implementações concretas dos observers, apenas a interface.
Extensibilidade: novos comportamentos podem ser adicionados sem alterar o código existente (Open/Closed Principle).
Responsabilidade única: cada observer cuida de uma única integração, facilitando testes isolados.

Desvantagens / trade-offs:

Ordem de execução implícita: se um observer depender do resultado de outro, a ordem da lista passa a importar — e isso não é óbvio ao ler o código.
Notificação síncrona por padrão: na implementação acima, se um observer for lento (ex: a API do CRM demorar para responder), todos os demais esperam. Em produção, isso normalmente pede execução assíncrona (filas, threads ou eventos).
Depuração mais difícil: como o fluxo se espalha por várias classes desacopladas, rastrear "quem reagiu a quê" exige mais disciplina de logging do que uma sequência de chamadas diretas.

Conclusão

Resumo

O Observer Pattern resolveu, de forma elegante, um problema que na prática aparece toda vez que um único evento de negócio precisa disparar múltiplas reações independentes. Em vez de uma classe central acumulando conhecimento sobre CRM, WhatsApp, e-mail e analytics, cada integração passou a viver isolada em sua própria classe, e adicionar ou remover canais deixou de exigir tocar no fluxo principal de captação.

Visão Pessoal

Na prática, implementar esse padrão deixou claro como um problema de acoplamento que parece pequeno no início — "é só mais um if ali" — cresce rápido conforme o número de integrações aumenta. O que mais me chamou atenção foi como uma mudança estrutural simples (extrair uma interface e inverter quem conhece quem) já resolve boa parte do problema, sem precisar de nenhuma ferramenta ou biblioteca extra — é puramente uma questão de organização do código.

Call-to-Action

E você, já se pegou escrevendo um método gigante cheio de chamadas a serviços diferentes para o mesmo evento? Como resolveu (ou pretende resolver) esse desacoplamento no seu projeto? Comenta aqui embaixo! 👇

DEV Community: Davi Sousa Oliveira