Pular para conteúdo

Propostas — Resiliência WFM / eForce Ordem de Serviço

Projeto: DSB26201 · Assessment de Arquitetura e Integrações · Energisa Elaborado por: Syntropy Labs (Castellani) Status: Brainstorming de consultoria — não é achado confirmado nem arquitetura To-Be oficial

Aviso metodológico

Estas três propostas nasceram de uma discussão técnica sobre os gaps já documentados em integracao-wfm-eforce-ordem-servico.md (ausência de DLQ, dual-write, redrive artesanal) — não de uma sessão com a Energisa. Por isso vivem em 030-artefatos/, fora de 100-to-be/: pelo plano de trabalho, a arquitetura alvo (Fase 4) só vira base oficial depois da validação de Fase 3 com Norberto e Rômulo, seguida da rodada técnica com as áreas — validação que ainda não ocorreu. Tratar este material como To-Be antes disso inverteria a ordem que o próprio plano define.

Nenhuma das três foi validada com a Energisa. São uma primeira formulação técnica, com trade-offs explícitos, para servir de ponto de partida quando a discussão for retomada — não uma recomendação fechada.

As três propostas

# Proposta Resolve dual-write Resolve DLQ/redrive Resolve replay histórico Complexidade
1 Outbox + Knative Eventing + Inbox + RabbitMQ DLQ Sim (Outbox) Sim (Knative retry + RabbitMQ DLX/TTL) Não — não é o objetivo Média
2 Event Sourcing clássico (CQRS) Sim (efeito colateral do modelo) Parcial (replay resolve redrive, mas não é DLQ) Sim — é a razão de existir do padrão Alta — não recomendada no estado atual
3 Arquivo de eventos + replay via query Não — resolve outro problema Parcial (replay cobre redrive; DLQ ainda precisa da Proposta 1) Sim — sem a complexidade de reconstruir agregado Média

As propostas 1 e 3 são complementares (uma resolve o fluxo em tempo real, a outra o arquivo/replay histórico) e podem coexistir. A proposta 2 foi desenhada por completude — ver a seção "Por que não recomendada agora" no próprio documento — porque o problema real observado (dual-write, DLQ ausente, redrive artesanal) não exige reconstruir o estado de um agregado a partir do zero, que é o que justifica Event Sourcing.

Origem da discussão

Toda a análise parte da sessão de 12/08/2026 com o desenvolvedor do eForce (ver 030-artefatos/integracao-wfm-eforce-ordem-servico.md) e do precedente já registrado de Castellani propor um Event Store durante a Ata 10 (20/07/2026), aceito pela equipe mas nunca implementado (ver 030-artefatos/topologia-rede-kafka-openshift.md, tabela de riscos P1).

Ver também