Como aplicar event storming para modelagem de domínios complexos

1. Fundamentos do Event Storming e seus benefícios para domínios complexos

1.1. O que é Event Storming: origem, princípios e a técnica de workshops colaborativos

Event Storming é uma técnica de modelagem colaborativa criada por Alberto Brandolini, originalmente concebida para acelerar a compreensão de domínios complexos. Diferente de abordagens tradicionais que partem de diagramas estáticos, o Event Storming reúne especialistas de negócio e desenvolvedores em uma sala (física ou virtual) para mapear, em tempo real, todos os eventos que ocorrem no domínio. A técnica utiliza post-its coloridos, cada cor representando um elemento do modelo: eventos (laranja), comandos (azul), atores (amarelo), agregados (rosa) e políticas (roxo).

1.2. Por que domínios complexos exigem modelagem baseada em eventos

Domínios complexos, como sistemas financeiros, logísticos ou de saúde, apresentam alta incerteza, múltiplos stakeholders e regras de negócio que evoluem constantemente. Modelagens baseadas em eventos capturam a essência do comportamento do sistema — o que realmente acontece — em vez de se prenderem a estruturas de dados ou fluxos lineares. Isso permite lidar com exceções, concorrência e estados transitórios de forma natural.

1.3. Diferenças entre Event Storming e outras abordagens

Enquanto DDD tático foca em entidades e value objects após a descoberta do domínio, e UML tende a ser excessivamente formal e distante do negócio, o Event Storming prioriza a conversa e o alinhamento entre pessoas. O resultado não é um diagrama finalizado, mas um entendimento compartilhado que evolui com o tempo.

2. Preparação e configuração do workshop de Event Storming

2.1. Definindo o escopo do domínio

Antes do workshop, é fundamental delimitar o bounded context a ser explorado. Por exemplo, em um sistema de e-commerce, podemos focar no contexto de "Processamento de Pedidos". Os objetivos devem ser claros: "mapear o fluxo desde a criação do pedido até a entrega ao cliente".

2.2. Seleção de participantes

Os papéis essenciais incluem:
- Domain experts: conhecedores do negócio (analistas, product owners)
- Desenvolvedores: quem implementará o modelo
- Facilitador: guia a dinâmica, mantém o foco e registra decisões

2.3. Materiais e ambiente

Para workshops presenciais: post-its grandes, canetas coloridas, uma parede ampla e cronômetro. Para remotos: ferramentas como Miro ou Mural, com templates específicos de Event Storming.

3. Fase 1: Big Picture — mapeamento de alto nível

3.1. Identificação de eventos de domínio

Comece perguntando: "O que acontece no negócio?" Os participantes escrevem eventos em post-its laranja, no passado, como:

Pedido Criado
Pagamento Confirmado
Estoque Reservado
Nota Fiscal Emitida
Pedido Enviado
Entrega Realizada

3.2. Organização temporal e causal

Disponha os eventos em uma linha do tempo horizontal. Agrupe por fases do processo: Pré-pedido, Pós-pagamento, Logística. Identifique relações causais: "Pedido Criado" leva a "Pagamento Solicitado", que leva a "Pagamento Confirmado".

3.3. Identificação de pontos críticos

Marque gargalos com post-its vermelhos. Exemplo: "Estoque Insuficiente" é um evento que pode interromper o fluxo. Identifique políticas de negócio: "Se pagamento confirmado E estoque disponível, então reservar estoque".

4. Fase 2: Process Modeling — detalhamento de fluxos e decisões

4.1. Adição de comandos e atores

Agora, para cada evento, pergunte: "Quem dispara isso?" e "Qual ação causa esse evento?".

Comando: "Criar Pedido" (azul)
Ator: "Cliente" (amarelo)
Evento resultante: "Pedido Criado" (laranja)

4.2. Modelagem de agregados e entidades

Identifique objetos que sofrem mudanças de estado. Para o evento "Pedido Criado", o agregado "Pedido" surge. Para "Pagamento Confirmado", o agregado "Pagamento" é criado.

4.3. Inclusão de políticas e regras de negócio

Políticas são regras automáticas. Exemplo:

POLÍTICA: "Quando Pedido Confirmado E Pagamento Aprovado, então Reservar Estoque"

Trate exceções: "Se pagamento recusado, notificar cliente e cancelar pedido".

5. Fase 3: Design-Level — transição para a implementação técnica

5.1. Mapeamento de bounded contexts e context maps

Identifique fronteiras entre domínios. Por exemplo:

Contexto: "Vendas" (lida com Pedidos)
Contexto: "Estoque" (lida com Reservas)
Contexto: "Financeiro" (lida com Pagamentos)

Relacione-os: "Vendas" envia evento "Pedido Confirmado" para "Estoque" e "Financeiro".

5.2. Definição de eventos de integração

Eventos de domínio tornam-se contratos entre serviços:

Evento: PedidoConfirmado
Payload: { pedidoId, clienteId, valorTotal, itens }

5.3. Esboço de agregados, commands e sagas

Exemplo de saga para fluxo de pedido:

1. Command: CriarPedido → Evento: PedidoCriado
2. Command: ConfirmarPagamento → Evento: PagamentoConfirmado
3. Command: ReservarEstoque → Evento: EstoqueReservado
4. Se falha: Command: CancelarPedido → Evento: PedidoCancelado

6. Validação e iteração do modelo com o time

6.1. Técnicas de verificação

Simule cenários: "O que acontece se o pagamento for recusado após o estoque já ter sido reservado?" Caminhe pelo modelo com perguntas "e se..." e walkthroughs com domain experts.

6.2. Ajuste de inconsistências

Refatore eventos duplicados ou comandos mal nomeados. Exemplo: unificar "Pagamento Aprovado" e "Pagamento Confirmado" em um único evento.

6.3. Documentação viva do modelo

Registre decisões em um glossário compartilhado:

Evento: PedidoCriado
Descrição: Ocorre quando o cliente finaliza a compra
Trigger: Command CriarPedido
Agregado: Pedido

7. Do Event Storming para o código: integração com padrões arquiteturais

7.1. Tradução de eventos para Event Sourcing e CQRS

Cada evento torna-se um registro imutável no event store. Commands geram eventos que atualizam projeções de leitura.

7.2. Uso de agregados e commands como base para serviços de domínio

// Exemplo de handler (pseudocódigo)
Command: CriarPedido
Handler:
  1. Validar dados do pedido
  2. Criar agregado Pedido
  3. Aplicar evento PedidoCriado
  4. Publicar evento em fila

7.3. Exemplo prático: evento "Pedido Confirmado" vira um handler

Evento: PedidoConfirmado
Payload: { pedidoId: "123", clienteId: "456", valor: 150.00 }

Handler (Serviço de Estoque):
  1. Receber evento da fila
  2. Verificar disponibilidade de itens
  3. Se disponível: Command: ReservarEstoque
     Evento: EstoqueReservado
  4. Se indisponível: Command: NotificarCliente
     Evento: EstoqueInsuficiente

8. Armadilhas comuns e melhores práticas em projetos reais

8.1. Evitando modelagem excessiva

Foque no core domain. Se um fluxo é simples e raramente muda, não vale a pena detalhar em eventos. Pergunte: "Isso realmente agrega valor ao entendimento do domínio?"

8.2. Lidando com times remotos e assíncronos

Use quadros virtuais com templates prontos. Grave sessões para participantes que não puderam comparecer. Estabeleça um "dicionário de eventos" compartilhado.

8.3. Manutenção do modelo ao longo do tempo

O modelo não é estático. Crie revisões periódicas (ex.: a cada sprint) para incorporar novas descobertas de negócio. Mantenha um changelog de eventos e comandos.

Referências