Design: Event Modeling

Olá!

Este é mais um post da seção Design e, como prometido no post sobre Event Sourcing, chegou a hora de falar sobre Event Modeling.

A técnica foi concebida por Adam Dymitruk e é apresentada em detalhes no post What is Event Modeling?, em inglês, que serve de base para este post.

Vamos lá!

O que é Event Modeling?

Event Modeling é uma técnica de design onde eventos são cidadãos primeira classe. Em vez de pensar no sistema a partir de suas entidades, como é ferto usualmente, começa-se pelo fluxo de eventos possíveis na aplicação. A ideia central é que sistemas são, em essência, uma sequência de fatos.

Interessante. Não?

Os Três Blocos de Construção

O Event Modeling é propositalmente simples. São apenas três elementos fundamentais:

Eventos

Eventos são fatos — algo que aconteceu e não pode ser desfeito ou alterado. São registros do passado, sempre escritos no passado. Exemplos: PedidoRealizado, PagamentoConfirmado, QuartoReservado.

Repare que nem toda ação é um evento. Apenas aquelas que mudam o estado da aplicação são registradas. Isso te lembra algo? Se você estiver atento vai se lembrar imediatamente de Event Sourcing!

Comandos

Comandos representam a intenção do usuário de modificar o estado da aplicação. São a causa; os eventos são o efeito. Exemplos: RealizarPedido, ConfirmarPagamento, ReservarQuarto.

Nota: É comum que se atribua ao ator do sistema, usuário ou processo automatizado, o nome de trigger (gatilho). Este gatilho é, em algumas fontes, ilustrado como um quarto elemento. Mas, para fins gerais, consideremos apenas comandos neste momento – vai fazer mais sentido nos próximos posts, prometo!

Visões (Read Models)

Visões são as leituras do estado atual da aplicação, derivadas dos eventos acumulados ao longo do tempo. São o que o usuário vê em tela, como o resumo de um pedido ou um relatório.

Normalmente é como os sistemas CRUD se caracterizam, como armazenam o estado da aplicação. No entanto, no Event Modeling eles são um produto e não a principal fonte da verdade.

Esses três elementos — eventos, comandos e visões — são suficientes para modelar praticamente qualquer sistema. Simples. Não?

Os Quatro Padrões

Além dos blocos de construção, o Event Modeling define quatro padrões estruturais que descrevem como esses elementos se combinam:

• Fluxo principal: um comando é acionado, gera um evento, e a visão é atualizada. O padrão mais comum.
• Tradução: eventos externos (de outros sistemas) são traduzidos em eventos com significado no domínio. Por exemplo, coordenadas GPS convertidas em HóspedeRetornouAoQuarto.
• Automação: processadores em segundo plano reagem a eventos e disparam novos comandos automaticamente — como um processador de pagamentos que executa cobranças periódicas.
• Integração: combinação dos padrões anteriores para lidar com sistemas legados ou integrações complexas.

O Processo

A aplicação do Event Modeling segue um processo colaborativo que pode ser conduzido em workshops com times diversos — desenvolvedores, especialistas de domínio, designers, etc.

Brainstorming de Eventos

Todos os participantes listam os eventos que imaginam que o sistema deveria registrar. Neste momento, a regra é pensar livremente. A filtragem vem depois.

Linha do Tempo

Os eventos são organizados em ordem cronológica e revisados quanto à coerência do negócio. Aqui o modelo começa a ganhar forma.

Storyboard

Wireframes ou mockups são inseridos na linha do tempo, conectando os eventos às telas da aplicação. Cada campo da interface deve ter uma origem clara: de onde vem? Para onde vai?

Identificar os Comandos

Para cada ação do usuário nas telas, um comando é identificado e associado ao evento que ele origina. Ficam explícitas as entradas da aplicação. Aqui também entram os comandos originados por processos automáticos como visto em Automação.

Identificar as Visões

Para cada tela que exibe dados, uma visão é identificada e associada aos eventos que a alimentam. Ficam explícitas as saídas da aplicação.

Aplicar a Lei de Conway

Os eventos são agrupados em raias (swimlanes) que representam componentes autônomos. Cada raia pode pertencer a um time diferente, com sua própria responsabilidade e ciclo de entrega. Lembra-se dos Contextos Delimitados do DDD e da Lei de Conway? Pois é! Aqui eles são pensados intencionalmente.

Elaborar os Cenários

Por fim são elaboradas as especificações utilizando a linguagem Gherkin (Given-When-Then) são criadas para cada comando e visão. Exemplo:

"Dado que o hóspede está registrado e possui um método de pagamento cadastrado, quando ele tenta reservar um quarto, então uma reserva é criada."

Essas especificações substituem histórias de usuário isoladas, conectando o comportamento esperado diretamente ao modelo.

Por que usar Event Modeling?

Além de tornar o design mais claro e colaborativo, o Event Modeling traz benefícios práticos para a gestão do projeto:

• Estimativas sem especulação: o esforço de cada passo do fluxo pode ser medido empiricamente, tornando o planejamento mais previsível.
• Mudanças sem surpresas: reordenar ou adicionar funcionalidades tem custo claro e controlado.
• Segurança por design: o modelo torna evidente onde e quando dados sensíveis cruzam fronteiras da aplicação, facilitando auditorias.
• Paralelismo real: como os contratos entre os passos são explícitos, times diferentes podem trabalhar em paralelo com acoplamento mínimo.

Conclusão

Event Modeling é uma técnica poderosa precisamente por ser simples. Com apenas três elementos e quatro padrões, é possível modelar sistemas complexos de forma que todos os envolvidos — técnicos ou não — consigam compreender e contribuir.

Recomendo, tal como no post sobre Event Sourcinfg, a leitura do livro Understanding EventSourcing (em inglês), de Martin Dilger, que trata do assunto com maior profundidade.

Com este post foi possível entender, de forma introdutória, como o Event Modeling funciona. Se você já teve contato com a técnica, entretanto, pode estar sentindo falta do diagrama de eventos. Isso é proposital. A ideia é fixar os conceitos e, no próximo post, ilustrar uma aplicação de exemplo – cujo código será disponibilizado ao final da série.

Assim sendo, continue ligado!

Gostou? Me deixe saber pelos indicadores do post e, caso queira, deixe um comentário.

Muito obrigado pela leitura e até o próximo post!