Arquitetura Baseada em Eventos (Event-Driven)

A Arquitetura Baseada em Eventos (EDA) é um padrão fundamental em nosso ecossistema de saúde para garantir o desacoplamento e a escalabilidade do sistema. Diferente de uma arquitetura imperativa tradicional, onde um componente chama diretamente uma função de outro, em um sistema EDA, os componentes reagem a fatos que já ocorreram.

O que é um Evento de Domínio?

Um evento de domínio é uma notificação de algo relevante que aconteceu no negócio. Ele descreve um fato passado e imutável.

• Exemplo: CONSULTATION_STARTED (A consulta foi iniciada).
• Contra-exemplo: START_CONSULTATION (Este é um comando, não um evento).

Por que EDA na Saúde Digital?

Sistemas de telemedicina e prontuário eletrônico são complexos e interconectados. O uso de eventos traz benefícios críticos:

1. Resiliência: Se o domínio de Chat estiver temporariamente fora do ar, o domínio de Consultation ainda pode publicar o evento de início de consulta. O Chat processará esse evento assim que for restaurado, sem que o médico perceba qualquer falha no fluxo principal de atendimento.
2. Extensibilidade: Podemos adicionar novos domínios (ex: Prescrição, Agendamento, Audit Log) que reagem ao mesmo evento de início de consulta sem modificar uma única linha de código no domínio original.
3. Performance: Processos que não precisam de resposta imediata (como gerar um log de auditoria ou enviar um e-mail de confirmação) podem ser disparados de forma assíncrona, liberando a thread principal para a interação com o usuário.

Fluxo de Comunicação

O fluxo segue o padrão Publisher-Subscriber (Pub/Sub) através de um barramento central:

[Domínio Origem] -> Publica Evento (Fato) -> [Barramento Central]
                                                     |
                                         +-----------+-----------+
                                         |                       |
                               [Domínio Interessado A] [Domínio Interessado B]
                                     (Reage)                 (Reage)

Regras de Ouro da EDA

Para manter o sistema saudável, seguimos princípios rigorosos:

• Imutabilidade: Uma vez publicado, um evento não pode ser alterado.
• Nomes no Passado: Eventos sempre indicam algo que já aconteceu (ex: USER_LOGGED_IN, APPOINTMENT_SCHEDULED).
• Payload Minimalista: O evento deve conter apenas o necessário para identificar o contexto (geralmente IDs e timestamps). O assinante deve buscar detalhes adicionais se necessário, garantindo que o evento não se torne um "objeto pesado" transitando pelo sistema.
• Idempotência: O assinante deve ser capaz de processar o mesmo evento múltiplas vezes sem causar efeitos colaterais indesejados, protegendo o sistema contra duplicidade de mensagens.

Esta abordagem teórica permite que o monorepo cresça de forma orgânica, preparando o terreno para uma futura transição para microfrontends ou microsserviços sem dor.