Pular para conteúdo

Board read-only orientado a eventos

O que é

Princípio arquitetural central do kanban-comercial: o usuário não arrasta card. O board é uma projeção do estado real, não a fonte de verdade dele. Cada ação de negócio de verdade acontece nas telas legadas (análise, propostas, bancarização) ou chega por webhook externo; essa ação emite um evento de domínio, e é o evento — não o clique do usuário no board — que move o negocio de coluna.

Os "botões" visíveis no card (Pegar, ✓ Aceito, Docs OK, Assinado etc.) são atalhos: eles disparam a ação real correspondente (que por sua vez emite o evento), não movem o card diretamente. A única exceção é "Mover para…", um override manual explícito no menu ⋮.

Como funciona (fluxo do evento)

use-case emite → fila mesa-analise.eventos
  → MesaAnaliseEventosDispatcher (fan-out)
  → fila negocios.eventos
  → NegocioEventosProcessor aplica a transição no agregado Negocio
  → persiste
  → Supabase Realtime
  → board invalida (debounce ~500ms, cirúrgico por pipe)

Handlers de evento são idempotentes; dual-write é best-effort (evento emitido após o commit — falha vira logger.error com payload replayable). Um cron (ReconciliarNegociosCronService) materializa cards que porventura ficaram faltando.

Por que isso importa

Evita duas fontes de verdade competindo (o board e as telas legadas) e evita que o usuário "minta" pro sistema arrastando um card sem que a ação de negócio correspondente tenha realmente acontecido.

Relacionado

kanban-comercial · negocio · pipe-e-etapa · comercial