O que é Event Storming?

Alberto Brandolini desenvolveu o EventStorming em encontros de modelagem ligados à comunidade de Domain-Driven Design. Seu livro em desenvolvimento, Introducing EventStorming, apresenta a prática como aprendizado coletivo deliberado e explora seu uso para compreender processos, conflitos e modelos de software.

Não há um ano de criação único que a fonte consultada permita afirmar com segurança. A técnica ganhou variações, de exploração ampla de um negócio a sessões focadas numa funcionalidade. O formato visual ajuda, mas as perguntas entre pessoas com conhecimento diferente são o centro da prática.

O facilitador reúne pessoas que enxergam partes diferentes do trabalho: quem atende clientes, decide regras, opera o serviço e constrói software. Uma superfície longa permite ordenar eventos relevantes ao longo de uma linha do tempo. Eventos de domínio são fatos que já aconteceram, escritos no passado, como “Pedido recebido” ou “Pagamento recusado”. Eles ajudam o grupo a falar sobre o que muda no negócio, sem começar por telas ou tabelas.

Comece pelo fluxo, não pela notação perfeita. Pessoas colocam eventos que conhecem e apontam casos estranhos, lacunas e exceções. Podem surgir eventos fora de ordem ou com nomes diferentes para a mesma coisa; isso é material de investigação. Arrumar todos os cartões cedo demais pode esconder conflito de entendimento. O mapa inicial é um retrato provisório do que o grupo sabe, não documentação validada.

Use eventos para descobrir regras. Entre “Solicitação enviada” e “Solicitação aprovada”, alguém precisa decidir. Quem? Com que informação? O que acontece se faltar documento ou se a resposta atrasar? Essas perguntas revelam políticas, comandos, pessoas responsáveis e pontos de espera. Cores adicionais de notas podem distinguir elementos, mas a equipe deve combinar legenda e não se prender a uma convenção que atrapalhe a conversa.

Marque pontos quentes. Quando participantes discordam, a divergência pode indicar uma regra ambígua, uma exceção frequente ou dois contextos que usam a mesma palavra com significados diferentes. Em vez de votar rapidamente, registre a pergunta e identifique quem pode respondê-la. Um ponto quente não é defeito da oficina; muitas vezes é seu achado mais valioso.

Faça a linha do tempo contar histórias. Percorra cenários comuns e também exceções: pagamento falha, cliente cancela, pedido volta para análise. Pergunte onde o fluxo começa para o cliente e onde o valor é de fato entregue. Um diagrama só do “caminho feliz” pode parecer completo e falhar na primeira situação real. Exemplos concretos ajudam especialistas a confirmar ou corrigir termos.

Reconheça fronteiras de linguagem. Em um trecho do mapa, “pedido aprovado” pode significar aprovação comercial; em outro, autorização de crédito. O DDD usa contextos delimitados para manter modelos coerentes nessas áreas. Event Storming pode revelar candidatos a fronteiras, mas uma parede de notas não define automaticamente arquitetura ou microsserviços. A decisão requer análise posterior de regras, pessoas, integrações e capacidades operacionais.

Escolha a escala da sessão. Uma exploração ampla pode mapear um serviço de ponta a ponta e encontrar oportunidades. Uma sessão de processo detalha interações e políticas num fluxo. Uma sessão de desenho de software aprofunda comandos, eventos e agregados numa parte delimitada. Não é preciso tentar resolver os três objetivos na mesma reunião. Declare a pergunta do encontro e onde ele termina.

A prática é visual, mas não exige papel físico. Num time remoto, um quadro colaborativo com espaço amplo pode funcionar se todos puderem contribuir e a facilitação cuidar de participação. A ferramenta não compensa ausência de especialistas ou uma reunião em que apenas uma pessoa fala. Reserve tempo para leitura silenciosa, contribuições simultâneas e perguntas específicas.

Da oficina à decisão. Fotografe ou preserve o mapa, mas também registre perguntas abertas, hipóteses e responsáveis por investigá-las. Escolha o que precisa de entrevista, teste de regra, análise de dados ou protótipo. Se a equipe simplesmente transforma todos os cartões em tarefas, pode perder o aprendizado sobre o problema. O mapa deve ajudar a decidir, não apenas abastecer um Backlog.

Event Storming pode apoiar Product Discovery ao mostrar experiências e decisões que estavam espalhadas entre áreas. Pode complementar um Service Blueprint, que organiza também atividades visíveis e bastidores de um serviço. Nenhum deles substitui observar usuários quando a pergunta é sobre a experiência de uso.

Evite confundir evento com ação desejada. “Enviar e-mail” é uma ação; “Confirmação enviada” é um fato ocorrido. A distinção não é preciosismo: fatos permitem perguntar que decisão ou evento os causou e que consequência vem depois. Ainda assim, não force reescritas intermináveis. Se a linguagem do grupo revela a regra, refine a notação quando ajudar.

A equipe pode terminar com um mapa incompleto e ainda ter feito progresso real, se identificou uma política contraditória e um caminho para resolvê-la. Não precisa produzir arquitetura final, requisitos fechados ou consenso total. O valor está em tornar visível o que estava implícito e criar linguagem suficiente para o próximo experimento ou decisão.

Imagine uma biblioteca hipotética que deseja permitir renovação online. O grupo reúne 8 pessoas de atendimento, acervo, operação e software. No começo, alguém coloca “Renovação solicitada” e “Prazo estendido” lado a lado. Outra pessoa pergunta o que acontece quando há uma reserva de outro leitor. O número de participantes e o cenário são ilustrativos.

A linha cresce: “Empréstimo iniciado”, “Reserva registrada”, “Renovação solicitada”, “Elegibilidade verificada”, “Renovação negada” ou “Prazo estendido”, “Leitor informado”. Surgem dois pontos quentes. A equipe de atendimento acredita que uma reserva pendente bloqueia qualquer renovação; acervo afirma que há exceção quando existem outros exemplares disponíveis. Além disso, o aviso ao leitor pode sair horas depois da decisão.

Antes, a equipe de software tinha apenas o pedido “criar botão de renovar” e poderia implementar uma regra incompleta. Depois, sabe que precisa investigar a política de exemplares, distinguir decisão de comunicação e decidir como informar negativa. O grupo registra quem confirmará cada regra e escolhe um primeiro recorte de entrega que mostra elegibilidade e motivo.

O mapa também revela que “disponível” significa algo diferente no catálogo e no atendimento: um exemplar pode aparecer livre na busca, mas estar reservado para retirada. Isso sugere fronteiras de modelo a examinar. Não obriga a criar dois serviços técnicos naquele momento. A próxima etapa é validar a distinção com exemplos reais e testar o comportamento escolhido.

Num contexto fora de TI, a mesma técnica poderia explorar a jornada de uma solicitação de benefício. Eventos como “Documento recebido”, “Análise iniciada” e “Decisão comunicada” tornam filas e divergências de política visíveis, mesmo que nenhuma linha de código seja escrita depois. O objetivo da oficina é aprender como o serviço funciona e onde precisa mudar.

Curso K21 recomendado