EventStorming do zero: Aprenda a entender oque o Cliente quer

Imagine que uma equipe receba a tarefa de construir um sistema para uma loja virtual.

A primeira reação pode ser abrir o editor e começar:

Pedido
Cliente
Produto
Pagamento
Estoque
Entrega

Depois aparecem as classes, tabelas, endpoints e serviços.

O problema surge algumas semanas mais tarde.

O desenvolvedor considera que um pedido existe assim que o cliente clica em Comprar. O setor financeiro considera que o pedido só está confirmado depois do pagamento. O estoque separa o produto antes disso. O atendimento permite cancelamentos. A transportadora não aceita cancelamento depois da coleta.

Todos conheciam o sistema.

Só não conheciam o mesmo sistema.

EventStorming existe para colocar essas versões diferentes da realidade na mesma superfície e obrigá-las a se encontrar.

Ele é um formato colaborativo de workshop criado por Alberto Brandolini em 2013. Inicialmente surgiu como uma forma rápida de modelar processos complexos dentro do contexto de Domain-Driven Design, mas evoluiu para aplicações em processos, organizações, serviços e design de software.

O ponto central não são os post-its.

É fazer pessoas com conhecimentos diferentes construírem juntas uma representação do que realmente acontece.

Antes de modelar software, descubra o que acontece no negócio

Considere este requisito:

O sistema deve permitir realizar pedidos.

Parece simples.

Mas tente responder:

Quando exatamente um pedido passa a existir?
O estoque é reservado antes ou depois do pagamento?
O pagamento pode ser recusado?
Um pedido pago pode ser cancelado?
Quem pode cancelar?
O que acontece se o pagamento for aprovado, mas não houver estoque?
Quando uma entrega passa a ser responsabilidade da transportadora?
O cliente pode alterar o endereço depois da compra?

Essas perguntas parecem detalhes de implementação.

Não são.

Elas descrevem regras do domínio.

Domínio, nesse contexto, significa a área do problema que estamos tentando entender: vendas, logística, matrículas escolares, empréstimos, reservas de hotel, folha de pagamento ou qualquer outro negócio.

Um erro comum é transformar requisitos vagos diretamente em código.

EventStorming introduz uma etapa anterior:

Entender o que acontece
        ↓
Entender por que acontece
        ↓
Entender quem toma decisões
        ↓
Entender quais regras existem
        ↓
Só então discutir como o software deve representar isso

É uma diferença pequena na ordem das atividades, mas enorme no resultado.

O elemento mais importante do EventStorming é o evento

O primeiro conceito que você precisa aprender é Domain Event, ou evento de domínio.

Um evento descreve alguma coisa relevante que já aconteceu.

Por isso normalmente escrevemos eventos no passado.

Em uma loja:

Pedido realizado
Pagamento aprovado
Pagamento recusado
Produto reservado
Pedido cancelado
Pedido enviado
Pedido entregue

Em uma escola:

Aluno matriculado
Matrícula cancelada
Nota registrada
Aluno aprovado
Aluno reprovado

Em um banco:

Conta aberta
Transferência solicitada
Transferência aprovada
Transferência recusada
Saldo debitado

Observe que:

Aprovar pagamento

não é um evento.

É uma ação que alguém deseja executar.

Já:

Pagamento aprovado

descreve algo que aconteceu.

Essa distinção será importante daqui a pouco.

Por que começar pelos eventos e não pelas classes?

Porque pessoas de áreas diferentes normalmente conseguem conversar sobre acontecimentos antes de conseguirem conversar sobre modelos de software.

Perguntar:

Quais classes precisamos?

praticamente entrega a conversa aos programadores.

Perguntar:

O que acontece desde o momento em que o cliente decide comprar até receber o produto?

permite que vendedor, desenvolvedor, atendimento, financeiro, logística e especialista do negócio participem da mesma conversa.

Essa é uma característica central do EventStorming: atravessar fronteiras entre especializações e permitir que perspectivas diferentes sejam colocadas no mesmo modelo.

Além disso, acontecimentos revelam dependências.

Se temos:

Pedido realizado
        ↓
Pagamento aprovado
        ↓
Produto reservado
        ↓
Pedido enviado

imediatamente podemos perguntar:

O produto só deveria ser reservado depois do pagamento?

Talvez alguém responda:

Não. Nós reservamos antes porque dois clientes poderiam comprar a última unidade.

Pronto.

Encontramos uma regra de negócio que provavelmente não apareceria em um diagrama de classes criado cedo demais.

O primeiro mapa provavelmente ficará bagunçado — e isso é útil

Em um workshop de exploração, várias pessoas podem adicionar eventos ao mesmo tempo.

Uma escreve:

Pagamento confirmado

Outra:

Pagamento aprovado

Outra:

Compra paga

A primeira reação de um programador talvez seja interromper tudo e decidir qual termo é tecnicamente correto.

Isso pode ser prematuro.

O próprio material oficial de EventStorming recomenda evitar precisão excessiva durante fases exploratórias: perspectivas conflitantes podem revelar que pessoas diferentes realmente entendem o processo de maneiras diferentes.

Talvez os três termos sejam sinônimos.

Talvez não.

Pode existir uma diferença real entre:

Pagamento autorizado
Pagamento capturado
Pagamento conciliado

E descobrir essa diferença pode ser muito mais valioso do que produzir rapidamente um quadro bonito.

EventStorming não tenta esconder a confusão existente no negócio.

Ele tenta torná-la visível.

Um exemplo completo: descobrindo como funciona uma loja virtual

Vamos construir um pequeno EventStorming.

Imagine a seguinte pergunta:

O que acontece desde a compra até a entrega?

Primeiro registramos apenas acontecimentos.

Carrinho criado

Produto adicionado ao carrinho

Pedido realizado

Pagamento solicitado

Pagamento aprovado

Produto reservado

Pedido separado

Pedido enviado

Pedido entregue

Em uma sessão física, Domain Events são tradicionalmente representados por post-its laranja.

Por enquanto, a cor é menos importante que a semântica.

O evento deve dizer:

alguma coisa relevante aconteceu.

Colocar os acontecimentos em ordem começa a revelar o processo

Agora organizamos os eventos aproximadamente no tempo:

Produto adicionado ao carrinho
            ↓
Pedido realizado
            ↓
Pagamento solicitado
            ↓
Pagamento aprovado
            ↓
Produto reservado
            ↓
Pedido separado
            ↓
Pedido enviado
            ↓
Pedido entregue

Esse fluxo é chamado frequentemente de happy path: o cenário em que tudo funciona.

Ele é útil para começar.

Mas sistemas reais raramente vivem apenas nele.

Pergunte:

O que mais pode acontecer aqui?

Logo aparecem novos eventos:

Pagamento recusado

Pagamento expirado

Reserva de estoque recusada

Pedido cancelado

Entrega atrasada

Entrega recusada

Pedido devolvido

Agora o mapa começa a representar um sistema de verdade.

Hot Spots: marque problemas sem paralisar o workshop

Durante a conversa alguém provavelmente dirá:

Espera. O cliente consegue cancelar depois de o pedido ter sido enviado?

Outra pessoa responde:

Acho que consegue.

Alguém da logística:

Não deveria.

Essa discussão pode consumir vinte minutos.

EventStorming possui o conceito de Hot Spot para registrar pontos que precisam de investigação sem necessariamente interromper o fluxo inteiro.

Você poderia marcar:

🔥 É possível cancelar depois da coleta da transportadora?

E continuar.

Essa prática é especialmente útil quando aparecem exceções ou alternativas enquanto a equipe ainda tenta construir um fluxo básico. O material oficial descreve exatamente esse uso: registrar objeções ou complexidades como Hot Spots, completar primeiro um cenário de referência e depois retornar aos casos problemáticos.

Um Hot Spot não significa:

isso não importa.

Significa:

isso importa tanto que não queremos esquecê-lo, mas resolver agora destruiria o ritmo da investigação.

Depois dos eventos aparecem os comandos

Voltemos a:

Pedido realizado

Alguma coisa fez esse evento acontecer.

Talvez um cliente tenha executado:

Finalizar compra

Isso é um Command.

Command representa uma intenção de provocar alguma mudança.

Compare:

COMMAND                     EVENTO

Finalizar compra      →     Pedido realizado

Aprovar pagamento     →     Pagamento aprovado

Cancelar pedido       →     Pedido cancelado

Despachar pedido      →     Pedido enviado

O padrão é:

"faça alguma coisa"
        ↓
"alguma coisa aconteceu"

Isso começa a aproximar o mapa do comportamento que posteriormente poderá existir no software.

Quem executa o comando?

Nem todo comando aparece sozinho.

Perguntamos:

Quem decidiu fazer isso?

No caso de:

Finalizar compra

provavelmente:

Cliente

Então podemos representar:

Cliente
   ↓
Finalizar compra
   ↓
Pedido realizado

Mas considere:

Despachar pedido

Talvez quem execute seja:

Operador da expedição

O mapa agora contém pessoas, decisões e acontecimentos.

Isso ajuda a diferenciar:

o que alguém deseja fazer

de:

o que efetivamente aconteceu.

Nem toda ação é iniciada diretamente por uma pessoa

Considere:

Pagamento aprovado

Depois desse evento, o sistema precisa iniciar automaticamente a separação do pedido.

Ninguém precisa ficar olhando os pagamentos e clicando:

Separar pedido.

Existe uma regra:

QUANDO Pagamento aprovado
ENTÃO Solicitar separação

Esse tipo de comportamento pode ser representado por uma Policy.

Em termos simples:

uma Policy expressa uma regra segundo a qual determinado evento provoca uma nova ação.

O fluxo poderia ficar:

Pagamento aprovado
        ↓
[Quando pagamento for aprovado...]
        ↓
Solicitar separação
        ↓
Separação solicitada

Agora estamos descobrindo automações.

Um fluxo começa a parecer uma pequena máquina de decisões

Combine os elementos:

CLIENTE
   ↓
Finalizar compra
   ↓
Pedido realizado
   ↓
Solicitar pagamento
   ↓
Pagamento solicitado

Um sistema externo processa o pagamento:

Gateway de pagamento
   ↓
Pagamento aprovado

Uma regra reage:

Pagamento aprovado
        ↓
POLICY:
Quando pagamento for aprovado,
solicitar reserva dos produtos
        ↓
Reservar produtos
        ↓
Produtos reservados

Depois:

Produtos reservados
        ↓
Solicitar separação
        ↓
Separação solicitada

O EventStorming começou com frases simples escritas em post-its.

Agora já revelou:

estados importantes;
ações;
responsáveis;
integrações externas;
automações;
regras;
dependências.

Ainda não escrevemos uma linha de código.

Esse é exatamente o ponto.

Onde entram os Aggregates?

Quando o objetivo deixa de ser apenas entender o processo e passa a envolver design de software, podemos aprofundar o modelo.

Aqui aparece um conceito importante de Domain-Driven Design: o Aggregate.

Pense neste comando:

Cancelar pedido

Ele não deveria simplesmente alterar qualquer informação do banco.

Existe alguma coisa responsável por decidir:

Esse pedido pode ser cancelado neste momento?

Podemos imaginar um Aggregate chamado:

Pedido

Então:

Cancelar pedido
        ↓
[Pedido]
        ↓
Pedido cancelado

O Aggregate protege regras importantes.

Por exemplo:

Se status = ENTREGUE
→ cancelamento não permitido

Se status = ENVIADO
→ talvez iniciar devolução em vez de cancelamento

Se status = AGUARDANDO_PAGAMENTO
→ cancelamento permitido

Em pseudocódigo:

class Pedido {

    Status status;

    void cancelar() {
        if (status == Status.ENTREGUE) {
            throw new IllegalStateException(
                "Pedido entregue não pode ser cancelado"
            );
        }

        status = Status.CANCELADO;

        registrarEvento(new PedidoCancelado());
    }
}

Esse código é apenas uma possível implementação.

O EventStorming não determina que você tenha de escrever exatamente essa classe.

A descoberta importante veio antes:

Cancelar pedido
      ↓
Pedido decide se a operação é válida
      ↓
Pedido cancelado

O modelo de software começa a nascer das regras descobertas no negócio, e não o contrário.

EventStorming não é a mesma coisa que Event Sourcing

Esse é um dos mal-entendidos mais comuns.

Os nomes parecem relacionados:

EventStorming
Event Sourcing

Mas são coisas diferentes.

EventStorming é uma técnica de modelagem colaborativa e exploração.

Event Sourcing é uma abordagem arquitetural em que mudanças de estado são armazenadas como uma sequência de eventos.

Você pode executar um EventStorming e depois implementar um sistema tradicional usando:

Java
Spring
PostgreSQL
REST
CRUD

Não existe obrigação de utilizar Event Sourcing.

Também não existe obrigação de utilizar microserviços.

O site oficial apresenta EventStorming inclusive como ferramenta capaz de apoiar o design de software event-driven e Domain-Driven Design, mas isso descreve uma possibilidade de aplicação, não uma exigência arquitetural.

EventStorming também não significa “vamos desenhar a arquitetura”

Outro erro é iniciar a reunião perguntando:

Quantos microserviços teremos?

Isso pula justamente a parte que o EventStorming deveria ajudar a investigar.

Compare as perguntas.

Arquitetura primeiro

Vamos criar:

OrderService
PaymentService
StockService
DeliveryService

Agora precisamos encaixar o problema nessa arquitetura.

Domínio primeiro

O que acontece?

Quem decide?

Quais regras existem?

Onde aparecem conflitos?

Quais informações precisam estar juntas?

Quais partes mudam por motivos diferentes?

Somente depois discutimos fronteiras de software.

Essa diferença é particularmente importante quando EventStorming é usado junto de Domain-Driven Design.

Existem diferentes níveis de EventStorming

Não existe apenas um único formato de sessão.

O material oficial apresenta aplicações diferentes para exploração de organizações, processos, serviços e design de software.

Uma divisão bastante útil é pensar em três níveis.

Big Picture

Pergunta:

Como esse negócio ou grande domínio funciona?

O objetivo é enxergar uma área ampla.

Por exemplo:

Cliente conhece produto
↓
Compra realizada
↓
Pagamento
↓
Estoque
↓
Expedição
↓
Transporte
↓
Entrega
↓
Pós-venda
↓
Devolução

Não tente modelar cada campo de banco.

Queremos enxergar o território.

O site oficial inclusive observa que o Big Picture se beneficia de grande espaço físico de modelagem e que sua execução remota exige cuidados adicionais de facilitação.

Process Modelling

Agora escolhemos um processo específico.

Por exemplo:

Como funciona o cancelamento de um pedido?

Podemos analisar:

Cancelamento solicitado
↓
Elegibilidade verificada
↓
Cancelamento aprovado
↓
Estorno solicitado
↓
Pagamento estornado
↓
Estoque liberado

Começam a aparecer exceções, responsáveis e regras.

Software Design

Finalmente aprofundamos comportamentos que serão implementados.

Perguntamos:

Qual comando produz esse evento?

Que informação é necessária?

Quem decide se o comando é válido?

Qual regra dispara a próxima ação?

Que parte do modelo mantém consistência?

Aqui Aggregates e outros conceitos relacionados ao design tornam-se particularmente relevantes.

Como fazer uma sessão de EventStorming

Não existe uma única sequência rígida válida para todos os contextos.

O próprio catálogo oficial trata padrões como orientações que precisam ser adaptadas ao contexto, e não como uma receita absoluta.

Mas existe uma estrutura bastante segura para sua primeira sessão.

1. Defina uma pergunta concreta

Evite:

Vamos modelar nosso sistema.

É amplo demais.

Prefira:

Como um pedido vai da compra até a entrega?

ou:

O que acontece desde a inscrição do aluno até a matrícula?

ou:

Como uma transferência bancária é processada?

O escopo fornece direção sem antecipar a resposta.

2. Coloque as pessoas que realmente conhecem partes diferentes do processo

Imagine uma loja.

Somente desenvolvedores provavelmente conhecem bem o software.

Mas talvez não conheçam completamente:

vendas
financeiro
estoque
expedição
atendimento
logística

Se você modela apenas com programadores, existe o risco de representar o que o software faz, não necessariamente como o negócio funciona.

O valor aumenta quando conhecimentos complementares entram na mesma conversa.

3. Prepare muito espaço

Em uma sessão presencial, uma parede longa ou grande superfície de papel é melhor que tentar encaixar tudo em um pequeno quadro.

O padrão oficial chamado Unlimited Modelling Space chama atenção justamente para esse problema: limitar artificialmente o espaço pode levar as pessoas a reduzir detalhes ou focar cedo demais em uma parte do problema.

Você precisará de:

post-its;
marcadores;
superfície ampla;
uma legenda visível.

E material sobrando.

Uma recomendação oficial de facilitação é fornecer um marcador para cada participante, reduzindo pequenas barreiras à contribuição paralela.

4. Comece perguntando “o que aconteceu?”

Não explique quinze símbolos durante vinte minutos.

Comece com eventos.

Exemplo:

Escrevam acontecimentos relevantes do processo, um por post-it, usando frases no passado.

As pessoas começam:

Pedido realizado

Pagamento aprovado

Produto separado

Pedido enviado

No começo haverá duplicações e contradições.

Tudo bem.

A própria orientação oficial sobre Incremental Notation recomenda começar com o mínimo necessário — especialmente os eventos — e adicionar novas formas de notação conforme a equipe precise delas.

5. Deixe todos contribuírem em paralelo

Não transforme o facilitador em secretário.

Uma situação ruim seria:

Participante fala
        ↓
Facilitador interpreta
        ↓
Facilitador escreve
        ↓
Facilitador coloca na parede

Você criou um gargalo.

Melhor:

Pessoa A escreve
Pessoa B escreve
Pessoa C escreve
Pessoa D escreve

simultaneamente.

Depois o grupo organiza.

O objetivo não é produzir consenso antes de escrever.

É tornar as diferentes perspectivas visíveis.

6. Organize os eventos aproximadamente no tempo

Agora os participantes aproximam eventos relacionados:

Pedido realizado
        ↓
Pagamento solicitado
        ↓
Pagamento aprovado
        ↓
Produto reservado
        ↓
Pedido enviado

Não trate a linha do tempo como uma precisão matemática.

Ela serve para ajudar a contar a história.

7. Leia a história em voz alta

Não apenas contemple o quadro.

Conte a história:

O cliente realiza um pedido. Depois o pagamento é solicitado. Quando o pagamento é aprovado, os produtos são reservados...

Provavelmente alguém interromperá:

Não. A reserva acontece antes da aprovação.

Ótimo.

Esse é exatamente o tipo de descoberta que queremos.

O padrão oficial Speaking out loud recomenda narrar o modelo em voz alta justamente porque isso ajuda a revelar inconsistências que podem passar despercebidas quando apenas olhamos o quadro.

8. Marque dúvidas e conflitos

Encontrou algo não resolvido?

Não esconda.

Registre:

🔥 Quando exatamente o estoque é reservado?

🔥 O cliente pode cancelar depois do envio?

🔥 Quem assume o prejuízo de uma entrega recusada?

Um quadro cheio de perguntas relevantes pode ser mais valioso que um quadro bonito cheio de certezas falsas.

9. Adicione comandos

Agora pergunte:

O que provocou esse acontecimento?

Se existe:

Pedido cancelado

talvez tenha existido:

Cancelar pedido

Monte:

Cancelar pedido
        ↓
Pedido cancelado

Repita pelo fluxo.

10. Descubra quem toma as decisões

Pergunte:

Quem iniciou este comando?

Pode ser:

Cliente
Atendente
Administrador
Sistema
Operador

Exemplo:

Cliente
   ↓
Cancelar pedido
   ↓
Pedido cancelado

Mas nem sempre é uma pessoa.

11. Procure regras automáticas

Pergunte:

Quando esse evento acontece, existe alguma coisa que obrigatoriamente deve acontecer depois?

Exemplo:

Pagamento aprovado
        ↓
Quando pagamento for aprovado,
solicitar separação
        ↓
Solicitar separação

Agora uma regra invisível tornou-se explícita.

12. Identifique sistemas externos

Talvez parte do processo dependa de:

Gateway de pagamento
ERP
Sistema dos Correios
Transportadora
Serviço antifraude
API governamental

Coloque essas dependências no modelo.

Imagine descobrir que:

Pagamento aprovado

não significa necessariamente dinheiro recebido porque o gateway trabalha com autorização e captura separadas.

Esse detalhe pode alterar completamente o processo de cancelamento e estorno.

É exatamente esse tipo de conhecimento que um modelo superficial tende a esconder.

13. Só depois aprofunde o design de software

Quando a história do negócio estiver suficientemente entendida, investigue:

Commands
Policies
Aggregates
Boundaries
Read Models
Integrações

A ordem importa.

Primeiro:

problema

Depois:

modelo

Depois:

software

Não:

framework
↓
arquitetura
↓
tentativa de encaixar o problema

Uma cerimônia prática de 90 minutos para iniciantes

“Cerimônia” não é uma nomenclatura obrigatória do método. O termo mais comum é workshop ou sessão de EventStorming.

Para aprendizado, porém, podemos organizar uma sessão curta.

O próprio projeto oficial disponibiliza Starter Kits de Big Picture e Process Modelling pensados para experiências colaborativas de aproximadamente 90 minutos.

0–10 minutos — contexto

O facilitador explica a pergunta.

Exemplo:

Vamos descobrir o que acontece desde um cliente finalizar uma compra até o produto ser entregue.

Explique apenas o necessário:

Um evento é algo relevante que aconteceu.

Escreva um acontecimento por post-it.

Use frases no passado.

Não dê uma aula completa de DDD.

10–25 minutos — tempestade de eventos

Todos escrevem eventos simultaneamente.

Exemplo:

Pedido realizado
Pagamento solicitado
Pagamento aprovado
Pagamento recusado
Produto reservado
Pedido cancelado
Produto separado
Pedido enviado
Pedido entregue

Duplicatas são permitidas.

Discordâncias são permitidas.

25–40 minutos — construir a linha do tempo

O grupo organiza acontecimentos.

Você pode acabar com:

Pedido realizado
        ↓
Pagamento solicitado
       ↙ ↘
aprovado   recusado
   ↓
Produto reservado
   ↓
Pedido separado
   ↓
Pedido enviado
   ↓
Pedido entregue

Agora começam as perguntas.

40–50 minutos — Hot Spots

Registre conflitos.

🔥 Quando o estoque é reservado?

🔥 Existe prazo máximo para pagamento?

🔥 Quando o cancelamento deixa de ser permitido?

🔥 Quem inicia o estorno?

Não tente resolver todos.

50–65 minutos — comandos e responsáveis

Transforme:

Pedido realizado

em:

Cliente
   ↓
Finalizar compra
   ↓
Pedido realizado

Faça isso com os pontos mais importantes.

65–75 minutos — policies e automações

Procure regras:

Pagamento aprovado
        ↓
Quando pagamento for aprovado...
        ↓
Reservar produtos
        ↓
Produtos reservados

75–85 minutos — narrar e quebrar o modelo

Conte a história inteira.

Depois deixe de ser gentil com ela.

Pergunte:

E se o pagamento for recusado?

E se houver apenas uma unidade?

E se duas pessoas comprarem ao mesmo tempo?

E se o gateway cair?

E se o cliente cancelar depois do despacho?

E se a transportadora devolver o pacote?

O material oficial chama atenção para esse passo no padrão Raise the Bar: depois de construir um cenário básico, introduzir casos extremos ajuda a testar se o modelo realmente suporta a complexidade do domínio.

85–90 minutos — decidir o que acontece depois

Não termine simplesmente tirando uma foto do quadro.

Extraia ações:

Investigar regra de cancelamento.

Confirmar comportamento do gateway.

Conversar com responsável pelo estoque.

Modelar separadamente o processo de devolução.

Criar testes para pagamento recusado.

O resultado de EventStorming não precisa ser “um diagrama final”.

Ele pode ser uma lista muito melhor das perguntas que precisam ser respondidas.

Como saber se a sessão funcionou

Um quadro bonito não prova nada.

Uma boa sessão costuma produzir descobertas como:

Achávamos que “pagamento confirmado” significava a mesma coisa para todos, mas financeiro e desenvolvimento estavam falando de estados diferentes.

Ou:

Descobrimos que ninguém sabia quem era responsável pelo cancelamento depois da expedição.

Ou:

O software permite uma operação que o processo real não permite.

Ou:

Dois departamentos executam a mesma validação.

Ou:

Uma única etapa chamada “processar pedido” escondia cinco decisões diferentes.

Isso é mais importante que a quantidade de post-its.

O livro oficial de Brandolini descreve EventStorming justamente como uma forma de aprendizado coletivo deliberado e destaca sua capacidade de expor impedimentos, conflitos e diferentes perspectivas sobre processos complexos.

O facilitador não deveria ter todas as respostas

Essa função é fácil de entender errado.

O facilitador não é necessariamente:

a pessoa mais experiente no domínio

nem:

o arquiteto que vai desenhar a solução correta

Sua função principal é manter o processo de descoberta funcionando.

Isso envolve coisas como:

evitar que uma única pessoa domine;
pedir exemplos concretos;
tornar divergências visíveis;
impedir discussões infinitas;
estimular participação;
controlar energia e tempo;
registrar assuntos que precisam ser retomados.

Uma pergunta simples costuma funcionar melhor que uma explicação longa:

O que acontece depois disso?

ou:

Quem faz isso?

ou:

O que fez esse evento acontecer?

ou:

Isso sempre acontece?

ou:

O que acontece quando dá errado?

O que costuma destruir um EventStorming

Transformar tudo em uma palestra

Se alguém passa quarenta minutos ensinando símbolos antes de qualquer participante tocar no quadro, perdeu-se boa parte da natureza exploratória.

A orientação oficial Do first, explain later recomenda fornecer inicialmente apenas as informações essenciais e introduzir explicações adicionais quando surgirem necessidades concretas.

Tentar eliminar divergências cedo demais

Se duas pessoas contam histórias diferentes, não force imediatamente uma versão única.

A divergência pode ser justamente a descoberta.

Chamar somente desenvolvedores

Você provavelmente obterá um excelente modelo da percepção que os desenvolvedores possuem sobre o negócio.

Isso não significa que será um excelente modelo do negócio.

Começar discutindo banco de dados

Se a conversa inicial virar:

Essa tabela terá UUID?

Essa relação será 1:N?

Vamos usar MongoDB?

Kafka ou RabbitMQ?

o workshop desceu para implementação cedo demais.

Essas perguntas podem ser importantes.

Só não são as primeiras.

Modelar apenas o caminho feliz

Se existe apenas:

Pedido realizado
↓
Pagamento aprovado
↓
Pedido enviado
↓
Pedido entregue

você modelou uma demonstração de vendas.

Não necessariamente um sistema real.

Tratar as cores como religião

As cores ajudam a criar uma linguagem visual.

Elas não são o objetivo.

Mantenha uma legenda visível e consistência durante a sessão. A própria documentação oficial dá mais importância à compreensão compartilhada da notação que à busca prematura por definições perfeitas.

EventStorming não substitui documentação

Outro exagero seria pensar:

Fizemos EventStorming, então não precisamos documentar nada.

O quadro registra uma exploração.

Dependendo do projeto, ainda será necessário transformar descobertas em:

requisitos

user stories

diagramas

ADRs

documentação de APIs

testes de aceitação

modelos de domínio

backlog

decisões arquiteturais

Uma possibilidade particularmente útil é transformar fluxos descobertos em testes.

Por exemplo:

Dado que um pedido foi realizado
E que o pagamento foi aprovado
Quando a reserva de estoque for processada
Então os produtos disponíveis deverão ser reservados

O padrão oficial Extract Acceptance Tests recomenda justamente utilizar modelos construídos em Process Modelling ou Software Design para extrair comportamentos verificáveis, inclusive usando a estrutura Given/When/Then quando apropriado.

O EventStorming ajuda a descobrir o que deve ser documentado e testado.

Não elimina essa necessidade.

Quando EventStorming faz sentido

Ele tende a ser especialmente interessante quando existe complexidade causada por pessoas e regras.

Por exemplo:

processo atravessa vários departamentos;

requisitos são contraditórios;

ninguém entende o fluxo completo;

sistema legado possui comportamentos pouco documentados;

produto novo ainda precisa ser descoberto;

negócio possui muitas exceções;

área técnica e área de negócio usam linguagens diferentes.

Imagine modernizar um sistema antigo de 15 anos.

Antes de reescrevê-lo, talvez seja muito mais importante descobrir:

Por que ele faz essas coisas estranhas?

Algumas “gambiarras” podem representar regras de negócio que ninguém mais documentou.

Quando pode ser exagero

Você não precisa reunir dez pessoas diante de uma parede para implementar:

GET /health

nem para construir uma página estática com três campos.

Ferramentas de modelagem possuem custo.

EventStorming começa a justificar esse custo quando existe algo relevante a descobrir colaborativamente.

Uma regra prática melhor que “use sempre” é:

Existe conhecimento importante distribuído entre várias pessoas que precisamos combinar para entender este problema?

Se a resposta for não, talvez uma conversa simples seja suficiente.

O produto mais importante não é o quadro

Depois de uma sessão, alguém pode perguntar:

Onde está o resultado?

A resposta aparentemente óbvia seria:

Na parede.

Mas o artefato visual é apenas parte dele.

Antes do workshop:

Desenvolvedor → conhece software

Financeiro → conhece pagamento

Estoque → conhece reserva

Atendimento → conhece cancelamentos

Depois de uma boa sessão:

Desenvolvedor ─┐
Financeiro ─────┤
Estoque ────────┼→ modelo compartilhado
Atendimento ────┘

Esse aprendizado coletivo explica por que Brandolini descreve EventStorming como “an act of deliberate collective learning” — um ato de aprendizado coletivo deliberado.

O quadro serve para tornar esse aprendizado visível.

Depois de aprender EventStorming, você começa a programar fazendo perguntas diferentes

Antes:

Qual classe preciso criar?

Depois:

Que acontecimento estamos tentando representar?

Antes:

Qual endpoint precisamos?

Depois:

Quem está tentando fazer o quê e por quê?

Antes:

Qual tabela guarda isso?

Depois:

Que regra determina se essa mudança é permitida?

Antes:

Precisamos de microserviços?

Depois:

Onde existem responsabilidades e modelos que realmente precisam evoluir separadamente?

Essa mudança não elimina código, arquitetura ou banco de dados.

Ela melhora o problema que chega até eles.

Esse talvez seja o principal motivo para um programador estudar EventStorming.

Programar bem não significa apenas transformar requisitos em código rapidamente.

Às vezes significa descobrir, antes de escrever o código, que ninguém tinha entendido completamente o requisito.

Meta title: EventStorming: guia prático do zero ao workshop

Meta description: Aprenda EventStorming do zero: eventos, comandos, policies, aggregates e um roteiro prático para conduzir seu primeiro workshop de 90 minutos.

Slug: eventstorming-guia-pratico

Tags: EventStorming, Domain-Driven Design, DDD, Domain Events, modelagem de software, arquitetura de software, desenvolvimento de software, workshops, design de software

Fontes utilizadas

EventStorming — site oficial — define EventStorming como formato de workshop colaborativo para exploração de domínios complexos e descreve suas aplicações em organizações, serviços e software.
Introducing EventStorming — Alberto Brandolini, Leanpub — livro do criador da técnica, utilizado como referência para objetivos, fundamentos e ideia de aprendizado coletivo deliberado.
Introducing EventStorming — página oficial do livro — histórico do método, criado por Brandolini em 2013, evolução e relação com Domain-Driven Design.
EventStorming Resources — site oficial — documentação dos Starter Kits e workshops de aproximadamente 90 minutos, além das modalidades de Process Modelling e Software Design.
EventStorming Patterns — documentação oficial — catálogo de padrões e antipadrões de facilitação.
Incremental Notation — EventStorming — referência para introduzir a notação progressivamente, começando pelos eventos.
Fuzzy Definitions — EventStorming — referência sobre não buscar precisão prematura durante a exploração.
Unlimited Modelling Space — EventStorming — referência sobre espaço de modelagem e efeitos de restrições artificiais durante o workshop.
One person/One Marker — EventStorming — referência para participação paralela e redução de gargalos durante workshops presenciais.
Speaking out loud — EventStorming — referência para narrar o fluxo em voz alta como forma de encontrar inconsistências.
Rush to the goal — EventStorming — referência sobre construir primeiro um fluxo básico e registrar complexidades como Hot Spots.
Raise the bar — EventStorming — referência para desafiar o modelo com exceções e casos extremos depois do cenário básico.
Extract Acceptance Tests — EventStorming — referência para transformar descobertas da modelagem em comportamentos verificáveis e testes de aceitação.
Do first, explain later — EventStorming — referência sobre evitar longas explicações teóricas antes de iniciar a experiência prática.