Event storming: workshop para descoberta de domínio e eventos

1. Fundamentos do Event Storming

1.1. Origem e princípios: de Alberto Brandolini ao Domain-Driven Design

O Event Storming foi criado por Alberto Brandolini por volta de 2013 como uma técnica colaborativa para explorar domínios complexos. Brandolini percebeu que as reuniões tradicionais de levantamento de requisitos falhavam em capturar a essência do negócio, gerando modelos desconectados da realidade. Inspirado pelos princípios do Domain-Driven Design (DDD) de Eric Evans, o Event Storming propõe um workshop intenso onde especialistas de domínio e desenvolvedores mapeiam juntos o comportamento do sistema através de eventos.

1.2. Objetivo principal: mapear comportamento do domínio através de eventos

O núcleo do Event Storming é responder à pergunta: "O que aconteceu no negócio?" Cada evento é um fato consumado, expresso no passado, como "PedidoConfirmado" ou "PagamentoRecebido". Diferente de requisitos funcionais tradicionais (que descrevem o que o sistema deve fazer), eventos descrevem o que já ocorreu, criando uma base sólida para modelagem de domínio.

1.3. Diferença entre Event Storming, Event Sourcing e Domain Storytelling

  • Event Storming: workshop colaborativo para descoberta de domínio e eventos.
  • Event Sourcing: padrão arquitetural onde o estado é derivado de uma sequência de eventos armazenados.
  • Domain Storytelling: técnica de modelagem baseada em narrativas e atores, mas sem o foco explícito em eventos como fato central.

O Event Storming frequentemente antecede a implementação de Event Sourcing, mas não é um pré-requisito obrigatório.

2. Preparação e Dinâmica do Workshop

2.1. Papéis dos participantes

  • Especialistas de domínio: pessoas que conhecem profundamente as regras de negócio (analistas de negócio, product owners, usuários-chave).
  • Desenvolvedores: responsáveis por entender o domínio para construir o software.
  • Facilitador: guia o workshop, mantém o ritmo e garante que todos participem, sem dominar a conversa.

2.2. Materiais necessários

Para workshops presenciais: post-its coloridos, canetas grossas e uma parede ampla. Para remoto: ferramentas como Miro ou Mural, com templates específicos de Event Storming.

2.3. Regras de colaboração

  • Foco no negócio, não em tecnologia.
  • Sem julgamento técnico durante a fase de descoberta.
  • Ritmo acelerado: cada post-it deve ser colocado em segundos, não minutos.
  • Todos podem contribuir, independentemente do cargo.

3. Big Picture: Descoberta do Fluxo de Eventos

3.1. Identificação de eventos de domínio (laranja)

Eventos são escritos no passado e representam fatos relevantes para o negócio. Exemplos:

PedidoCriado
PagamentoAprovado
EstoqueAtualizado
NotaFiscalEmitida
EntregaAgendada

Cada post-it laranja contém um verbo no particípio passado + substantivo, como "ClienteCadastrado".

3.2. Ordenação temporal dos eventos em linha do tempo

Os eventos são dispostos da esquerda para a direita em uma linha do tempo. Isso revela a sequência lógica do fluxo de negócio.

[PedidoCriado] -> [PagamentoAprovado] -> [EstoqueSeparado] -> [NotaFiscalEmitida] -> [EntregaRealizada]

3.3. Detecção de fronteiras de contexto (Bounded Context)

Agrupamentos naturais de eventos indicam limites de contexto. Por exemplo, eventos de pagamento formam um grupo coeso, enquanto eventos de logística formam outro. Esses grupos se tornam candidatos a Bounded Contexts no DDD.

Contexto de Vendas: PedidoCriado, PedidoCancelado
Contexto de Pagamento: PagamentoSolicitado, PagamentoAprovado, PagamentoRecusado
Contexto de Logística: EntregaAgendada, EntregaRealizada

4. Modelagem de Processos com Comandos e Atores

4.1. Comandos (azul): ações que disparam eventos

Comandos representam intenções que disparam eventos. São escritos no imperativo, como "CriarPedido" ou "AprovarPagamento". Cada comando resulta em pelo menos um evento.

Comando: [CriarPedido] -> Evento: [PedidoCriado]
Comando: [AprovarPagamento] -> Evento: [PagamentoAprovado]

Atores (humanos ou sistemas) executam comandos. Exemplo: "Cliente" executa "CriarPedido", "SistemaPagamento" executa "AprovarPagamento".

4.2. Regras e políticas de negócio (roxo)

Regras validam se um comando pode ser executado. Exemplo:

Regra: [ValorMínimoPedido] -> valida se total >= R$ 10,00 antes de processar CriarPedido

Políticas são regras automáticas que disparam sem comando explícito. Exemplo:

Política: [CancelarPedidoApos7Dias] -> se Pagamento não aprovado em 7 dias, dispara PedidoCancelado

4.3. Identificação de pontos de entrada e saída por contexto

Cada Bounded Context possui comandos de entrada e eventos de saída. Isso define claramente as interfaces entre contextos.

Contexto de Vendas:
  Entrada: CriarPedido (ator: Cliente)
  Saída: PedidoCriado (evento publicado)

Contexto de Pagamento:
  Entrada: PedidoCriado (evento consumido)
  Saída: PagamentoAprovado (evento publicado)

5. Detalhamento com Agregados e Visões

5.1. Agregados (amarelo): entidades que recebem comandos e produzem eventos

Agregados são entidades que garantem consistência dentro de um contexto. Exemplo:

Agregado: [Pedido]
  - Recebe comando: AdicionarItem
  - Produz evento: ItemAdicionadoAoPedido
  - Mantém regra: valor mínimo de pedido

5.2. Visões de leitura (verde): projeções dos dados para consulta

Visões representam como os dados são consultados, separando leitura de escrita (CQRS implícito). Exemplo:

Visão: [ResumoPedido] -> exibe total, itens, status para o cliente
Visão: [RelatorioVendas] -> agrega dados para gerência

5.3. Hot spots e dúvidas (vermelho/rosa)

Pontos de incerteza são marcados com post-its vermelhos ou rosas. Exemplo:

Dúvida: O que acontece se o pagamento for aprovado após o cancelamento?
Hot spot: Regra de reembolso não definida para pagamentos parciais

Esses pontos devem ser resolvidos antes da implementação.

6. Transição para Arquitetura de Software

6.1. Mapeamento de eventos para schemas de mensageria

Cada evento identificado vira um schema em sistemas de mensageria como Kafka ou RabbitMQ. Exemplo de schema:

Evento: PedidoCriado
Schema:
{
  "eventId": "uuid",
  "eventType": "PedidoCriado",
  "timestamp": "2025-03-20T10:00:00Z",
  "data": {
    "pedidoId": "12345",
    "clienteId": "67890",
    "valorTotal": 150.00,
    "itens": [
      {"produtoId": "001", "quantidade": 2, "preco": 75.00}
    ]
  }
}

6.2. Definição de contratos entre contextos

Contextos se comunicam através de eventos. Para evitar acoplamento, usa-se Anti-corruption Layer (ACL) ou Shared Kernel.

Contexto Vendas -> publica: PedidoCriado
Contexto Pagamento -> consome: PedidoCriado (via ACL que traduz para seu modelo interno)

6.3. Governança de eventos: Schema Registry e versionamento

Eventos evoluem. Usa-se Schema Registry (Apache Avro, Confluent) para versionar schemas.

Versão 1: PedidoCriado (com campos: pedidoId, clienteId, valorTotal)
Versão 2: PedidoCriado (adiciona campo: cupomDesconto)

Regra: eventos nunca são alterados retroativamente; novas versões são criadas.

7. Estratégias de Evolução Contínua

7.1. Ciclos iterativos: do Big Picture ao Design-Level

O Event Storming não é uma atividade única. Começa-se com Big Picture (visão geral) e, em iterações seguintes, aprofunda-se em contextos específicos (Design-Level).

7.2. Documentação viva: manutenção do mapa como artefato do time

O mapa gerado no workshop deve ser mantido atualizado, servindo como documentação viva do domínio. Ferramentas como Miro permitem versionamento e comentários.

7.3. Integração com práticas ágeis

Event Storming pode ser usado como pré-requisito para sprints que implementam Event Sourcing. Cada sprint foca em um Bounded Context mapeado.

8. Armadilhas Comuns e Boas Práticas

8.1. Evitar detalhamento técnico precoce

Não discuta bancos de dados, filas ou microsserviços durante o Big Picture. Foco exclusivo no domínio.

8.2. Cuidado com eventos genéricos demais

"StatusAlterado" é muito genérico. Prefira "PedidoConfirmado" ou "PedidoCancelado". A granularidade deve refletir fatos atômicos do negócio.

8.3. Engajamento dos especialistas

O facilitador deve garantir que especialistas de domínio falem mais que desenvolvedores. Evite jargões técnicos. Use perguntas como: "O que acontece depois que o pedido é criado?"

Referências