Event Bus em Delphi: construindo uma arquitetura orientada a eventos com Callbacks, Fluent Interface e SOLID

Última atualização em 3 de junho de 2026 por Willian Tuttoilmondo

Event Bus em Delphi é uma abordagem arquitetural que permite que diferentes partes de uma aplicação se comuniquem sem depender diretamente umas das outras. Em vez de um componente chamar outro componente explicitamente, eventos são publicados em um barramento central e entregues automaticamente aos interessados, promovendo baixo acoplamento e maior flexibilidade na evolução do sistema. Aprender a implementar este recurso em Delphi pode parecer complexo, mas é mais simples do que se imagina.

À medida que aplicações crescem, é comum encontrar rotinas responsáveis por executar múltiplas ações ao mesmo tempo: registrar logs, enviar notificações, atualizar dashboards, auditar operações e persistir informações. Embora funcionem inicialmente, essas implementações criam dependências rígidas entre componentes e tornam a manutenção cada vez mais complexa. O resultado é uma arquitetura difícil de testar, reutilizar e expandir.

Neste artigo construiremos um Event Bus em Delphi utilizando interfaces, callbacks, Fluent Interface e princípios SOLID. Além de implementar um mecanismo completo de publicação e assinatura de eventos, veremos como criar uma arquitetura orientada a eventos, desacoplada e extensível, capaz de servir como base para aplicações modernas, APIs RESTful e sistemas corporativos de grande porte.

Neste artigo você aprenderá:

• O que é Event Bus em Delphi
• Como implementar Publish/Subscribe
• Como criar eventos tipados com Generics
• Como executar assinantes assíncronos com TTask
• Como aplicar SOLID em arquiteturas orientadas a eventos
• Como integrar Event Bus a APIs RESTful

O que é um Event Bus e quais problemas ele resolve

Um Event Bus é um mecanismo de comunicação que permite que diferentes partes de uma aplicação troquem informações sem depender diretamente umas das outras. Em vez de um componente chamar outro componente explicitamente, ele apenas publica um evento em um barramento central, ficando a cargo do Event Bus localizar e notificar todos os componentes interessados naquela informação.

Em uma aplicação tradicional, é comum encontrar serviços que conhecem detalhadamente todas as ações que devem ser executadas após uma determinada operação. Ao criar um pedido, por exemplo, a mesma rotina pode ser responsável por registrar logs, enviar notificações, atualizar indicadores, persistir informações de auditoria e acionar integrações externas. Embora essa abordagem funcione em sistemas pequenos, ela cria um forte acoplamento entre os componentes da aplicação.

Considere o exemplo de um sistema de vendas. Sempre que um pedido é criado, diversas ações podem precisar ser executadas. Uma implementação tradicional poderia ser semelhante a esta:

Neste cenário, o serviço responsável pela criação do pedido precisa conhecer todos os demais serviços envolvidos no processo. Sempre que uma nova funcionalidade for adicionada, como o envio de uma mensagem para um sistema externo ou a atualização de um relatório, o código da operação original precisará ser modificado. Isso viola princípios importantes de arquitetura, como o Open/Closed Principle, e torna a manutenção progressivamente mais complexa.

Com um Event Bus em Delphi, a responsabilidade muda completamente. Após concluir a operação, o serviço apenas publica um evento representando o que aconteceu:

A partir desse momento, todos os componentes interessados no evento poderão reagir a ele de forma independente. O serviço que criou o pedido não precisa conhecer os consumidores do evento, nem saber quantos são ou quais ações executam. O único compromisso existente é a publicação do evento.

Essa abordagem reduz significativamente o acoplamento entre componentes, melhora a reutilização de código, simplifica testes unitários e torna a aplicação mais flexível para evoluir ao longo do tempo. Novas funcionalidades podem ser adicionadas através da criação de novos assinantes, sem que seja necessário alterar o código responsável pela publicação dos eventos.

Em outras palavras, um Event Bus transforma a comunicação direta entre componentes em uma comunicação orientada a eventos, permitindo que sistemas complexos sejam construídos de forma mais organizada, escalável e alinhada com os princípios modernos de arquitetura de software.

Diferenças entre Event Bus, Observer e Callback Pattern

Ao estudar Event Bus em Delphi, é comum encontrar comparações com outros mecanismos de comunicação amplamente utilizados no desenvolvimento de software, especialmente os padrões Observer e Callback Pattern. Embora todos tenham como objetivo permitir que um componente reaja a eventos ou mudanças de estado, cada abordagem possui características próprias e atende a necessidades diferentes.

O Callback Pattern é a forma mais simples de comunicação entre componentes. Nele, um objeto recebe uma rotina ou método que será executado quando uma determinada operação for concluída. O componente responsável pela execução conhece explicitamente o callback que deverá ser chamado, estabelecendo uma relação direta entre quem produz e quem consome a informação.

Um exemplo simples de callback pode ser observado em uma operação matemática:

Nesse caso, existe apenas um produtor e um consumidor da informação. Quando a operação termina, o callback informado é executado diretamente pelo objeto responsável pelo processamento.

O padrão Observer amplia esse conceito permitindo que vários consumidores sejam notificados quando algo acontece. Um objeto, chamado de sujeito (Subject), mantém uma lista de observadores (Observers) e os notifica sempre que seu estado é alterado. Essa abordagem reduz parte do acoplamento existente nos callbacks tradicionais, mas ainda mantém uma dependência direta entre o sujeito e seus observadores.

Em aplicações Delphi, esse comportamento é bastante comum em componentes visuais. Um controle pode notificar diversos observadores quando seu estado muda, mas continua sendo responsável por gerenciar o ciclo de vida e o registro desses observadores.

O Event Bus, por sua vez, adiciona uma camada intermediária entre quem publica e quem consome eventos. Em vez de registrar observadores diretamente em um objeto específico, os eventos são publicados em um barramento central. Os assinantes registram interesse em determinados tipos de eventos e passam a ser notificados automaticamente quando esses eventos são publicados.

Essa arquitetura elimina o conhecimento mútuo entre produtores e consumidores. O componente responsável pela publicação de um evento não sabe quem irá recebê-lo, quantos assinantes existem ou quais ações serão executadas em resposta. Da mesma forma, os assinantes não precisam conhecer quem gerou o evento.

A principal diferença entre essas abordagens pode ser resumida da seguinte forma:

• Callback Pattern: comunicação direta entre produtor e consumidor.
• Observer: um produtor notifica múltiplos consumidores registrados diretamente nele.
• Event Bus: produtores e consumidores comunicam-se através de um barramento central, sem qualquer dependência direta entre si.

Por esse motivo, o Event Bus em Delphi é frequentemente utilizado em arquiteturas orientadas a eventos, sistemas corporativos e aplicações distribuídas, onde baixo acoplamento, extensibilidade e facilidade de manutenção são requisitos fundamentais. Embora callbacks e observadores continuem sendo extremamente úteis em diversos cenários, o Event Bus oferece uma solução mais flexível quando a comunicação entre múltiplos componentes precisa ocorrer de forma transparente e desacoplada.

Reduzindo o acoplamento entre componentes utilizando eventos

Um dos principais objetivos de uma arquitetura moderna é reduzir o acoplamento entre componentes. Quanto mais dependências diretas existem entre as partes de uma aplicação, maior é o impacto de qualquer alteração realizada no sistema. Mudanças simples podem exigir modificações em diversos módulos, aumentando a complexidade da manutenção e elevando o risco de introdução de novos defeitos.

Em aplicações tradicionais, é comum que uma classe conheça explicitamente todos os serviços necessários para concluir uma operação. Considere o processo de criação de um pedido em um sistema comercial. Após persistir os dados, a aplicação pode precisar enviar um e-mail de confirmação, registrar informações de auditoria, atualizar indicadores gerenciais e notificar sistemas externos. Uma implementação convencional poderia ser semelhante a esta:

Embora funcional, essa abordagem cria uma forte dependência entre o serviço responsável pela criação do pedido e todos os demais componentes envolvidos no processo. Cada nova funcionalidade adicionada exigirá alterações nessa rotina, fazendo com que a classe acumule responsabilidades que não pertencem ao seu domínio principal.

O problema se torna ainda mais evidente conforme a aplicação cresce. O componente responsável pela operação passa a conhecer detalhes de infraestrutura, integração, monitoramento e auditoria, tornando-se um ponto central de dependências. Além de dificultar a manutenção, essa situação viola princípios importantes de projeto, como o Single Responsibility Principle (SRP) e o Open/Closed Principle (OCP).

Uma forma eficiente de reduzir esse acoplamento é utilizar eventos para comunicar o que aconteceu dentro da aplicação. Em vez de executar diretamente todas as ações necessárias, o componente responsável pela operação publica um evento representando o fato ocorrido.

Nesse cenário, a responsabilidade do serviço passa a ser apenas criar o pedido e informar ao sistema que um novo pedido foi criado. Todas as demais ações deixam de ser uma preocupação direta dessa classe.

Os componentes interessados passam a atuar como assinantes do evento. Um serviço pode ser responsável pelo envio de e-mails, outro pela auditoria, outro pela atualização de indicadores e assim por diante. Cada consumidor registra interesse no evento e reage a ele de forma independente.

A grande vantagem dessa abordagem é que novos comportamentos podem ser adicionados sem qualquer alteração no código responsável pela publicação do evento. Para incluir uma nova funcionalidade, basta criar um novo assinante e registrá-lo no barramento de eventos.

Além de reduzir o acoplamento, uma arquitetura baseada em eventos favorece a reutilização de componentes, simplifica testes unitários e melhora significativamente a escalabilidade da aplicação. Como produtores e consumidores não possuem dependências diretas entre si, cada parte do sistema pode evoluir de forma independente, tornando a manutenção mais simples e previsível.

Ao utilizar um Event Bus em Delphi, a comunicação deixa de ser baseada em chamadas diretas entre objetos e passa a ser orientada a eventos. O resultado é uma arquitetura mais flexível, extensível e alinhada às práticas modernas de desenvolvimento de software.

Modelando eventos através de interfaces

Para construir um Event Bus em Delphi de forma flexível e extensível, o primeiro passo é definir como os eventos serão representados dentro da aplicação. Um evento deve descrever algo que já aconteceu no sistema, como um pedido criado, um pagamento aprovado, um usuário autenticado ou uma falha registrada durante uma integração.

Em vez de representar eventos apenas como classes soltas, podemos modelá-los através de interfaces. Essa abordagem permite definir um contrato comum para todos os eventos da aplicação, facilitando o registro, a publicação e o consumo desses objetos pelo barramento de eventos. Além disso, o uso de interfaces em Delphi permite aproveitar a contagem automática de referências, reduzindo a necessidade de controle manual do ciclo de vida dos objetos.

A interface base para qualquer evento pode ser bastante simples:

Nessa estrutura, todo evento terá um identificador, uma data de criação e um nome. Esses três elementos serão úteis mais adiante para auditoria, logs, rastreamento e depuração da aplicação.

Para evitar repetição de código em todos os eventos concretos, podemos criar uma classe base abstrata responsável por implementar esse comportamento comum.

Com essa base definida, cada evento concreto pode se concentrar apenas nos dados que realmente fazem sentido para o domínio. Em um sistema comercial, por exemplo, podemos modelar um evento para representar a criação de um pedido.

Também podemos criar outros eventos seguindo exatamente a mesma estrutura. Um evento de pagamento aprovado, por exemplo, poderia ser modelado desta forma:

Observe que nenhum desses eventos conhece o Event Bus, os assinantes ou os serviços que irão reagir a eles. Um evento deve ser apenas uma descrição imutável de algo que aconteceu no sistema. Essa separação é importante para manter o baixo acoplamento e preservar a clareza da arquitetura.

Com os eventos modelados através de interfaces, teremos uma base sólida para implementar o mecanismo de publicação e assinatura. Nas próximas etapas, esses eventos serão publicados no barramento e consumidos por callbacks tipados, permitindo que diferentes partes da aplicação reajam a acontecimentos do domínio sem dependências diretas entre si.

Criando callbacks tipados com Generics

Depois de modelarmos os eventos através de interfaces, o próximo passo para construir um Event Bus em Delphi é definir como os assinantes serão notificados. Para isso, utilizaremos callbacks tipados com Generics, permitindo que cada evento possua um método de tratamento fortemente tipado e seguro em tempo de compilação.

No artigo sobre Callback Pattern em Delphi, vimos que callbacks podem ser definidos usando reference to procedure. Essa mesma abordagem será utilizada aqui, mas agora combinada com Generics para que o tipo do evento seja preservado durante a assinatura e a publicação. Assim, um assinante de IOrderCreated receberá exatamente um evento do tipo IOrderCreated, sem necessidade de casts espalhados pelo código consumidor.

A primeira estrutura que precisamos criar é o tipo genérico do callback. Ele será responsável por representar qualquer rotina capaz de tratar um evento específico.

Com essa definição, podemos criar callbacks diferentes para cada tipo de evento da aplicação. Um evento de pedido criado poderá ser tratado por um callback específico para IOrderCreated, enquanto um evento de pagamento aprovado poderá ser tratado por outro callback específico para IPaymentApproved.

A principal vantagem dessa abordagem é a segurança de tipo. O compilador passa a impedir que um callback preparado para tratar um tipo de evento seja usado indevidamente para outro. Isso reduz erros em tempo de execução e torna o código mais claro para quem consome o Event Bus.

Um exemplo simples de utilização pode ser visto abaixo. Nesse cenário, criamos uma variável capaz de armazenar um callback para eventos do tipo IOrderCreated.

Embora esse exemplo ainda não publique eventos, ele já demonstra a base do mecanismo que utilizaremos no barramento. O callback recebe uma interface de evento concreta, acessa suas propriedades e executa alguma ação em resposta ao acontecimento ocorrido.

À medida que avançarmos na implementação do Event Bus, precisaremos armazenar esses callbacks internamente para que possam ser executados quando um evento for publicado. Para isso, vamos criar uma estrutura responsável por representar uma inscrição (subscription) dentro do barramento.

O primeiro passo é definir uma interface que represente uma assinatura de evento.

Essa interface será utilizada futuramente para controlar o ciclo de vida das inscrições, permitindo inclusive que um assinante seja removido do Event Bus quando não desejar mais receber notificações.

Agora podemos criar uma implementação concreta para essa assinatura. Ela armazenará um identificador único e o nome do evento associado ao registro.

Como estamos construindo um projeto funcional, também precisaremos de uma estrutura capaz de armazenar o callback associado à assinatura. Para isso, vamos criar uma versão genérica da inscrição, responsável por manter a referência do callback que será executado quando o evento for publicado.

A interface IEventSubscriptionInternal será usada internamente pelo Event Bus. Ela permitirá verificar se determinada assinatura é compatível com um evento publicado e, em caso positivo, despachar esse evento para o callback correspondente.

Essa classe será uma peça fundamental na implementação do padrão Publish/Subscribe, pois permitirá que o Event Bus mantenha uma coleção de assinaturas registradas e execute automaticamente os callbacks corretos quando um evento for publicado.

Neste ponto, já temos quatro elementos importantes para o nosso projeto:

• Uma interface base para eventos (IEvent);
• Eventos concretos modelados através de interfaces;
• Callbacks tipados utilizando Generics;
• Estruturas de assinatura para armazenar os callbacks registrados.

Esses componentes serão utilizados na próxima etapa para implementar o núcleo do Event Bus, responsável por registrar assinantes, publicar eventos e distribuir notificações para todos os consumidores interessados.

A combinação de callbacks com Generics torna o Event Bus mais expressivo, seguro e alinhado com uma arquitetura moderna em Delphi. Em vez de trabalhar com estruturas genéricas demais, como TObject, Pointer ou casts manuais, passamos a criar um fluxo de comunicação fortemente tipado, legível e muito mais fácil de manter.

Implementando o padrão Publish/Subscribe (Pub/Sub)

Depois de criarmos os eventos, os callbacks tipados e as estruturas de assinatura, podemos finalmente implementar o núcleo do nosso Event Bus em Delphi. É nesta etapa que o padrão Publish/Subscribe, também conhecido como Pub/Sub, começa a acontecer de fato.

A ideia central do Pub/Sub é simples: um componente publica um evento e todos os assinantes interessados naquele tipo de evento são notificados automaticamente. Quem publica não conhece quem consome. Quem consome não precisa conhecer quem publicou. Toda a comunicação passa a ser intermediada pelo Event Bus.

Para começar, definiremos a interface principal do barramento de eventos. Essa interface terá três responsabilidades básicas: registrar assinantes, remover assinaturas e publicar eventos.

A assinatura do método Subscribe utiliza Generics para garantir que o callback registrado seja compatível com o tipo do evento. Isso significa que, ao assinar um evento do tipo IOrderCreated, o callback receberá exatamente um IOrderCreated.

O método Publish, por sua vez, recebe um evento concreto e distribui esse evento para todos os assinantes registrados para aquele tipo. Já o método Unsubscribe permite remover uma assinatura previamente criada, evitando que o callback continue sendo executado.

Com todas as estruturas auxiliares já definidas, podemos implementar o Event Bus propriamente dito. Para armazenar os assinantes, utilizaremos uma lista de IEventSubscriptionInternal. Dessa forma, o barramento consegue manipular todas as assinaturas de maneira uniforme, independentemente do tipo específico do evento.

Agora já temos um Event Bus funcional com suporte ao padrão Publish/Subscribe. A assinatura é feita com Subscribe, a publicação é feita com Publish e a remoção de assinantes pode ser realizada com Unsubscribe.

Um uso inicial do barramento ficaria assim:

Também podemos registrar múltiplos assinantes para o mesmo evento. Essa é uma das principais vantagens do padrão Pub/Sub: uma única publicação pode disparar diversas ações independentes.

Com essa estrutura, o serviço responsável por criar um pedido não precisa conhecer os serviços de e-mail, auditoria ou dashboard. Ele apenas publica o evento IOrderCreated, e o Event Bus se encarrega de entregar esse evento a todos os interessados.

Esse é o ponto em que o Event Bus em Delphi começa a mostrar seu real valor arquitetural. O código deixa de ser baseado em chamadas diretas entre componentes e passa a ser organizado em torno de eventos. Isso reduz acoplamento, facilita a manutenção e permite que novas funcionalidades sejam adicionadas através de novos assinantes, sem modificar o fluxo principal da aplicação.

Construindo um Event Bus utilizando Fluent Interface

Até este ponto já construímos um Event Bus em Delphi totalmente funcional. Os eventos podem ser publicados através do método Publish, os consumidores podem se registrar utilizando Subscribe e as inscrições podem ser removidas através de Unsubscribe.

Embora essa implementação já resolva o problema da comunicação desacoplada entre componentes, ainda podemos melhorar significativamente sua experiência de uso. É aqui que entra o padrão Fluent Interface, responsável por transformar sequências de chamadas em uma API mais legível, intuitiva e agradável de utilizar.

Como todos os métodos principais do nosso barramento já retornam IEventBus, não precisamos criar uma classe auxiliar ou um builder adicional. O próprio Event Bus já possui a estrutura necessária para se comportar como uma API fluida.

Sem uma interface fluida, o registro de vários assinantes para um mesmo evento poderia ficar assim:

O código funciona, mas repete a chamada a TEventBus.Instance diversas vezes. Em um sistema real, com múltiplos eventos e vários assinantes, essa repetição rapidamente compromete a legibilidade.

Como o método Subscribe retorna a própria interface do barramento, podemos encadear todas as inscrições em um único fluxo.

A leitura desse código é bastante natural: obtemos a instância do Event Bus e registramos, em sequência, todos os assinantes interessados no evento IOrderCreated. Cada bloco representa uma reação diferente ao mesmo acontecimento de domínio.

A publicação de eventos também pode se beneficiar da mesma fluidez. Podemos publicar um evento isolado:

Ou, se fizer sentido para determinado fluxo da aplicação, publicar mais de um evento em sequência:

Embora publicar vários eventos em sequência não seja obrigatório, a possibilidade de encadear chamadas torna a API mais flexível e consistente. O ponto mais importante é que o consumidor passa a interagir com o Event Bus de maneira limpa, previsível e com baixa verbosidade.

Em termos arquiteturais, a Fluent Interface não altera o funcionamento interno do barramento. O que ela melhora é a experiência de consumo. O Event Bus continua responsável por registrar assinantes, publicar eventos e distribuir notificações, mas agora essa interação passa a ser escrita de forma mais próxima da linguagem natural.

Com isso, nosso Event Bus em Delphi passa a reunir três características importantes: comunicação desacoplada através de eventos, callbacks tipados para segurança em tempo de compilação e uma API fluida capaz de tornar o uso do barramento mais claro e elegante. Na próxima etapa, evoluiremos essa implementação para permitir o registro e a remoção dinâmica de assinantes.

Aplicando os princípios SOLID em uma arquitetura orientada a eventos

Ao construir um Event Bus em Delphi, não estamos apenas criando uma estrutura para publicar e assinar eventos. Estamos também organizando a comunicação entre componentes de forma mais alinhada com princípios modernos de arquitetura de software. Nesse contexto, os princípios SOLID ajudam a entender por que uma arquitetura orientada a eventos tende a ser mais flexível, extensível e fácil de manter.

O objetivo do SOLID não é adicionar complexidade ao código, mas reduzir dependências desnecessárias, separar responsabilidades e permitir que novas funcionalidades sejam adicionadas com menor impacto sobre o restante da aplicação. O Event Bus contribui diretamente para isso, pois faz com que publicadores e assinantes se comuniquem através de abstrações, sem dependências diretas entre si.

Single Responsibility Principle

O Single Responsibility Principle, ou princípio da responsabilidade única, afirma que uma classe deve ter apenas um motivo para mudar. Em uma implementação tradicional, é comum que um serviço de domínio acabe acumulando responsabilidades que não pertencem diretamente a ele.

Nesse exemplo, o serviço responsável pela criação do pedido também conhece regras de e-mail, auditoria, dashboard e notificação. Embora o código seja simples, ele concentra responsabilidades demais em uma única rotina.

Ao utilizar eventos, o serviço passa a ter uma responsabilidade mais clara: criar o pedido e publicar o fato de que ele foi criado.

Agora, cada ação derivada da criação do pedido pode ser tratada por um assinante específico. O envio de e-mail, o registro de auditoria e a atualização do dashboard deixam de ser responsabilidades do serviço de pedidos.

Open/Closed Principle

O Open/Closed Principle determina que entidades de software devem estar abertas para extensão, mas fechadas para modificação. Esse princípio fica bastante evidente em uma arquitetura baseada em eventos.

Se amanhã precisarmos enviar uma mensagem para um sistema externo sempre que um pedido for criado, não será necessário alterar o método CreateOrder. Basta adicionar um novo assinante para o evento IOrderCreated.

O comportamento da aplicação foi estendido sem modificar o código responsável pela criação do pedido. Esse é um dos maiores benefícios do Event Bus: novas reações a eventos podem ser adicionadas sem alterar o fluxo principal da regra de negócio.

Liskov Substitution Principle

O Liskov Substitution Principle afirma que implementações concretas devem poder substituir suas abstrações sem quebrar o comportamento esperado pelo sistema. No nosso Event Bus, esse princípio aparece principalmente no uso de interfaces para representar eventos.

Como o barramento trabalha com a interface IEvent, qualquer evento concreto que implemente esse contrato pode ser publicado e tratado pelo mecanismo de distribuição.

Da mesma forma, assinantes especializados podem trabalhar com contratos mais específicos, como IOrderCreated ou IPaymentApproved, desde que esses contratos preservem o comportamento esperado de um evento.

Essa substituição é segura porque todos os eventos concretos respeitam o contrato definido pelas interfaces. O Event Bus não precisa conhecer a classe concreta do evento, apenas o contrato que ele implementa.

Interface Segregation Principle

O Interface Segregation Principle recomenda que clientes não sejam obrigados a depender de métodos que não utilizam. No Event Bus, esse princípio aparece na separação entre interfaces públicas e interfaces internas.

A aplicação consumidora precisa conhecer apenas a interface pública da assinatura.

Já o Event Bus precisa de operações adicionais, como verificar se uma inscrição suporta determinado evento e despachar a notificação. Essas operações ficam em uma interface interna separada.

Com essa separação, o consumidor da API não é exposto a detalhes internos do barramento. Ele recebe uma assinatura, mas não precisa conhecer o processo de despacho dos eventos. Isso mantém a API pública mais simples e reduz o acoplamento com a implementação interna.

Dependency Inversion Principle

O Dependency Inversion Principle afirma que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Em uma arquitetura orientada a eventos, esse princípio é aplicado quando os componentes passam a depender de contratos, e não de implementações concretas.

O serviço responsável por criar pedidos não precisa conhecer TEmailService, TAuditService ou TDashboardService. Ele depende apenas da abstração representada pelo Event Bus e pelo contrato do evento publicado.

Essa pequena alteração torna o serviço mais fácil de testar, pois podemos fornecer uma implementação falsa de IEventBus durante os testes. Além disso, o serviço deixa de depender diretamente do Singleton TEventBus.Instance, ficando mais flexível para cenários reais de aplicação.

Com isso, o Event Bus deixa de ser apenas um utilitário global e passa a fazer parte de uma arquitetura orientada a abstrações. O resultado é um código mais testável, extensível e preparado para evoluir com menor impacto sobre o restante da aplicação.

Ao aplicar os princípios SOLID em uma arquitetura orientada a eventos, percebemos que o Event Bus não é apenas uma forma elegante de disparar notificações. Ele se torna uma ferramenta arquitetural para separar responsabilidades, reduzir acoplamento, favorecer extensões e permitir que diferentes partes da aplicação evoluam de maneira independente.

Registrando e removendo assinantes dinamicamente

Depois de implementar o padrão Publish/Subscribe e tornar a API do nosso Event Bus em Delphi fluida, o próximo passo é permitir que assinantes sejam registrados e removidos dinamicamente durante a execução da aplicação. Esse recurso é importante em sistemas reais, especialmente quando determinados componentes existem apenas temporariamente, como formulários, telas, módulos carregados sob demanda, rotinas de integração ou processos em segundo plano.

Até aqui, o método Subscribe registra um callback no barramento e o método Unsubscribe remove uma assinatura previamente registrada. Para que isso funcione de maneira segura, precisamos guardar a referência da assinatura retornada no momento do registro.

Considere um formulário que deseja ser notificado sempre que um pedido for criado. Ao abrir a tela, ele registra um assinante no Event Bus. Ao fechar a tela, ele remove essa assinatura para evitar que o callback continue sendo executado quando o formulário já não estiver mais disponível.

O método Open será responsável por registrar o assinante e guardar a assinatura retornada pelo Event Bus.

Já o método Close utilizará essa mesma assinatura para remover o assinante do barramento.

Essa abordagem é simples, mas poderosa. A aplicação passa a ter controle explícito sobre o ciclo de vida dos assinantes. Isso evita notificações indesejadas, reduz riscos de acessar objetos que já deveriam ter sido descartados e torna o comportamento do sistema mais previsível.

Para que esse fluxo funcione corretamente, o método Subscribe precisa retornar a assinatura criada. Na versão fluida apresentada anteriormente, fizemos Subscribe retornar IEventBus. Essa decisão melhora o encadeamento das chamadas, mas dificulta o armazenamento da assinatura retornada.

Uma forma elegante de resolver isso é separar duas intenções diferentes: registrar assinantes de forma fluida e registrar assinantes quando precisamos controlar explicitamente a assinatura criada. Para isso, adicionaremos um novo método chamado SubscribeFor.

Agora temos duas formas de registrar assinantes. O método Subscribe mantém a API fluida, ideal para configurações encadeadas. Já SubscribeFor retorna a assinatura criada, permitindo que o consumidor remova esse assinante posteriormente.

A implementação do Event Bus pode reaproveitar a mesma lógica nos dois métodos. O método SubscribeFor cria a assinatura, adiciona à lista interna e retorna a referência criada.

Com SubscribeFor implementado, o método fluido Subscribe pode simplesmente chamar esse novo método e retornar a própria instância do barramento.

A remoção continua sendo feita pelo método Unsubscribe, que percorre a lista de assinaturas procurando pelo identificador da assinatura informada.

Com essa alteração, podemos reescrever o exemplo do dashboard de forma mais apropriada.

Também podemos demonstrar o comportamento publicando um evento antes e depois da remoção da assinatura.

Nesse exemplo, o primeiro evento será recebido pelo dashboard, pois a assinatura ainda está ativa. Após a chamada a Close, a assinatura é removida do Event Bus. O segundo evento continuará sendo publicado normalmente, mas o dashboard não será mais notificado.

Essa capacidade de registrar e remover assinantes dinamicamente é essencial para aplicações reais. Ela permite que componentes participem do fluxo de eventos apenas enquanto fizer sentido, sem criar dependências permanentes ou callbacks órfãos. Em aplicações com formulários, módulos plugáveis, telas temporárias ou processos de longa duração, esse controle evita efeitos colaterais difíceis de rastrear.

Com SubscribeFor, mantemos o melhor dos dois mundos: uma API fluida para registros simples e uma API controlável para cenários em que o ciclo de vida da assinatura precisa ser gerenciado explicitamente. Na próxima seção, veremos como publicar eventos para múltiplos consumidores simultaneamente e como organizar esses assinantes de forma mais próxima de uma aplicação real.

Publicando eventos para múltiplos consumidores simultaneamente

Uma das principais vantagens do padrão Publish/Subscribe é permitir que um único evento seja consumido por diversos componentes ao mesmo tempo. Em uma arquitetura orientada a eventos, um acontecimento de domínio raramente interessa apenas a um único módulo da aplicação. Pelo contrário, é comum que diferentes partes do sistema reajam de maneiras distintas ao mesmo fato.

Considere novamente o evento IOrderCreated. Quando um pedido é criado, diversas ações podem precisar ocorrer simultaneamente: envio de e-mail, auditoria, atualização de dashboards, integração com sistemas externos e geração de métricas.

Quando o evento for publicado, todos os assinantes compatíveis serão executados automaticamente.

Essa característica transforma o Event Bus em uma poderosa ferramenta de extensão arquitetural. Novos comportamentos podem ser adicionados simplesmente registrando novos assinantes, sem modificar o fluxo principal da aplicação.

Criando eventos de domínio (Domain Events)

Nem todo evento representa apenas uma mensagem técnica. Em aplicações corporativas, é comum utilizar o conceito de Domain Events, que representam acontecimentos relevantes do domínio de negócio.

Um Domain Event descreve algo que já aconteceu e possui significado para a organização. Exemplos incluem:

• Pedido criado;
• Pagamento aprovado;
• Cliente bloqueado;
• Produto esgotado;
• Contrato cancelado.

Em vez de utilizar eventos genéricos, podemos criar contratos específicos para cada acontecimento de negócio.

Uma implementação concreta poderia ser construída da seguinte forma: