Proposta 2 — Event Sourcing clássico (CQRS)

Status: Brainstorming de consultoria — ver aviso metodológico Resolve: reconstrução de estado a partir de eventos, replay completo de agregado Recomendação: não recomendada para o WFM/eForce no estado atual — ver seção final

Contexto

Durante a discussão em chat, o pedido inicial foi "montar a arquitetura de Event Sourcing para sugerir à Energisa". Esta proposta desenha essa arquitetura por completude técnica — é o design pattern correto quando a exigência de negócio é reconstruir o estado de um agregado a partir do zero, com histórico completo e auditável. Ela é deliberadamente mais pesada que as Propostas 1 e 3, e essa diferença de peso é o ponto central da recomendação abaixo.

Diagrama C4 — Contêineres

Design patterns aplicados

Padrão	Papel nesta proposta
Event Sourcing	Estado do agregado nunca gravado diretamente — é derivado da sequência completa de eventos no Event Store
CQRS	Separação total entre o lado de comando (grava eventos) e o lado de consulta (read models otimizados por consumidor, ex.: LEGSCI e MsAttFiltroIncidentes)
Append-only Event Store	Coleção Mongo sem UPDATE — apenas INSERT, garantindo histórico imutável
Snapshotting	Snapshot periódico do agregado evita replay de todo o histórico a cada leitura
Optimistic Concurrency	Controle via {aggregateId, sequenceNumber} — evita condição de corrida entre comandos concorrentes sobre a mesma OS
Projections / Read Models	Cada consumidor downstream (LEGSCI, Atendimento) mantém seu próprio modelo de leitura, atualizado de forma eventualmente consistente

Cenários de aplicação

Cenário	Proposta se aplica?
Requisito de negócio explícito de reconstruir o estado de um agregado em qualquer ponto do tempo	Sim — é exatamente o que o padrão resolve
Múltiplos read models divergentes precisam da mesma fonte de eventos, cada um com sua própria forma de consulta	Sim
Auditoria regulatória exige histórico completo e imutável de mudanças de estado	Sim
Problema observado é dual-write, ausência de DLQ e redrive artesanal (caso real do WFM/eForce)	Não — nenhum desses três problemas exige reconstruir um agregado; Outbox + Inbox + DLQ (Proposta 1) resolve com muito menos complexidade
Necessidade é arquivar eventos para consulta ocasional e reenvio pontual, sem reconstruir agregado	Não — isso é a Proposta 3, mais simples e mais barata

Por que não recomendada agora

A Event Sourcing clássica é desproporcional aos problemas reais encontrados nesta sessão:

• O gap observado não pede reconstrução de estado. Dual-write, ausência de DLQ e redrive manual são resolvidos pela Proposta 1 (Outbox + Inbox + DLQ), sem exigir que o eForce abandone seu modelo de persistência atual em favor de um Event Store append-only.
• Bloqueio real de governança de schema. Um Event Store depende de contratos de evento estáveis e versionados — e o achado da Ata 14 (Engenharia de Dados) registra 0% de cobertura de Schema Registry no WFM. Sem isso, qualquer Event Store corre risco real de acumular eventos com formatos incompatíveis entre si, inviabilizando o replay que é a própria razão de existir do padrão.
• Complexidade operacional dobrada. CQRS exige manter dois modelos (comando e consulta) e lidar com consistência eventual entre eles — custo que só se paga quando múltiplos read models divergentes já são uma necessidade real, o que não foi observado no domínio WFM/eForce até agora.
• Nenhum stakeholder pediu isso. A ideia partiu de brainstorming de consultoria, não de um requisito de negócio articulado pela Energisa — reforça a cautela de não propor complexidade que ninguém demandou.

Este documento existe para não perder o desenho caso um requisito genuíno de reconstrução de estado apareça no futuro — mas a recomendação, hoje, é a Proposta 1 para o problema imediato e a Proposta 3 para arquivamento/replay.