Um dashboard operacional costuma precisar de mais do que o estado atual: a equipe quer saber como chegou ali, quais transições falharam e de onde vieram os totais. Event sourcing registra mudanças de domínio como um histórico ordenado e durável; as telas são projeções derivadas desse histórico. É útil quando auditoria ou múltiplas formas de consulta justificam o custo, não como substituto automático de tabelas convencionais.
Eventos devem descrever fatos como FaturaAprovada ou ProvisionamentoFalhou, não notificações vagas como “linha alterada”. Inclua ID, entidade, sequência, horários do fato e do registro, versão do esquema e IDs de correlação. Mantenha os dados pequenos e evite gravar segredos ou informações pessoais desnecessárias num log imutável.
| Pergunta | Projeção | Sinal de atualização |
|---|---|---|
| Quais tarefas exigem atenção? | Estado, próxima ação e responsável | Idade do evento pendente e última atualização |
| Onde os casos ficam parados? | Duração por etapa e transição | Atraso da projeção e tempo no estado |
| O que mudou neste turno? | Resumo de eventos por período | Marca do último evento processado |
| Como explicar este indicador? | Agregado com acesso às entidades de origem | Versão da projeção e horário de geração |
Não faça cada abertura do dashboard varrer todo o histórico. Materialize projeções para consultas reais e exponha a última posição processada para que dados atrasados fiquem visíveis. A projeção pode ser reconstruída, mas isso leva tempo: mostre “atualizado até” em vez de sugerir consistência instantânea.
Consumidores precisam tolerar entrega duplicada usando IDs dos eventos ou checkpoints de sequência. Defina o tratamento de eventos fora de ordem, lacunas, payloads inválidos e evolução do esquema. Quando possível, grave projeção e checkpoint juntos; caso contrário, uma falha pode pular ou aplicar o evento duas vezes. Encaminhe falhas para uma quarentena recuperável com responsável.
Reconstrua uma nova versão, compare contagens e invariantes e só então troque a leitura. Não repita efeitos externos, como enviar e-mails ou cobrar pagamentos, durante o replay. Snapshots podem acelerar a recuperação, desde que a combinação de snapshot e eventos posteriores também seja testada.
O comando pode ser aceito antes de todas as projeções serem atualizadas. Deixe isso explícito na API e na interface. Para ações críticas, devolva o resultado autorizado do comando em vez de consultar imediatamente uma visão atrasada e dizer que nada aconteceu. Monitore atraso, idade de eventos, erros de projeção e duração do replay.
Se basta consultar o estado atual e manter algumas colunas de auditoria, uma tabela convencional pode resolver melhor. Event sourcing adiciona evolução de esquemas, crescimento do histórico, ferramentas de replay, questões de retenção e consistência eventual. Faz mais sentido quando reconstrução histórica, múltiplas visões ou auditoria de negócio são requisitos centrais.
Use um histórico append-only como fonte para projeções operacionais explícitas. Versione eventos, processe com idempotência, exponha a atualidade da projeção e torne o replay seguro e observável. O dashboard é uma visão de leitura feita para decisões humanas, não o próprio event store. Adote o padrão quando o valor do histórico justificar sua complexidade.