Toró de Eventos (a.k.a Event Storming) é realmente tudo isso??

Toró de Eventos (a.k.a Event Storm) é realmente tudo isso??

O objetivo desse texto nem é muito explicar tecnicamente como funciona esse workshop, mas compartilhar a minha linha de raciocínio para se preparar/estudar para facilitar esse evento.

Aqui vale um disclaimer, essa foi a primeira vez que participei e ja comecei facilitando de um workshop desse tipo. Então até eu me convencer de que estava em um ambiente safe para testar e experimentar todo o processo a síndrome do impostor bateu forte! Depois que entendi todo esse cenário, minha mente destravou inclusive de coisas que eu precisaria estudar e preparar para tentar trazer o melhor resultado possível.

O que é Event Storm

Estou partindo da premissa que quem está lendo isso conhece um pouco de DDD. Escrevi um artigo sobre isso em 2019, da uma olhada aqui. Mas falando especificamente sobre o tema desse artigo, precisamos definir um pouco as coisas.

Lá em meados de 2013, um italiano chamado Alberto Brandolini (um Engenheiro de Software) sentia as dores de extrair do time de negócio quais as nuances e detalhes do problema que queriam resolver construindo um software. Sim, entendemos que um software existe para resolver um problema mas resgatando um pouco do que o Erick Evans (pai do DDD) trouxe no seu livro, esse software precisa também falar a língua do negócio.

Brandolini, criou um workshop que torna mais simples e colaborativo extrair do time de negócio todos os aspectos relevantes sobre o problema (que na nomenclatura do DDD chamamos de domínio) que estamos tentando entender. Por isso que para essa cerimônia funcionar, é interessante que tenham Especialistas de Domínio (pessoas que realmente entendem como o negócio funciona) para responder algumas perguntas que o time de engenharia vai fazer.

Basicamente separamos o timebox (reserve um bom tempo para o evento) em 4 etapas:

1 Coleta de Eventos

2 Refinamento

3 Identificação de causas

4 Reclassificação

Cada etapa tem seu objetivo específico e para a coisa não sair do controle, devemos estabelecer um tempo para execução de cada passo.

Coleta de Eventos

Aqui é onde quem conhece o domínio que queremos entender, começa a colocar na mesa tudo que acontece de relevante, mas pra isso é importante que tenha um formato específico no apontamento. Para ficar mais claro, vamos de exemplo:

Pensando que temos um hospital para administrar, o que de importante, sob a ótica de quem gerencia o mesmo, acontece e que precisamos deixar claro que aquele evento aconteceu?

• Cirurgia Iniciada
• Paciente Internado
• Atendimento realizado
• Pagamento recebido

E aqui vejam a importância de ter alguém que conheça o problema, porque as coisas que eu vou apontar são importantes sob a minha ótica que tenho zero experiência em administrar um hospital.

De qualquer forma, a fase de coleta de eventos é o momento que precisamos saber tudo de relevante que acontece, pois essa informação vai ser útil la na frente quando tivermos separando responsabilidades.

Refinamento

A etapa anterior vai nos gerar um monte de eventos que vamos precisar organizar nesse segundo momento. Aqui é onde tentamos colocar tudo em uma ordem cronológica (um paciente precisa ser internado antes de fazer uma cirurgia por exemplo) e discutimos os principais eventos.

Nesse momento também tiramos as duplicatas e fazemos as correções necessárias (adicionando ou removendo coisas que não são relevantes no momento).

xxxxxxx

Agora chegou a vez de encorpar mais tudo que foi gerado até agora. Se temos um evento (uma ação), precisamos identificar quem gerou essa ação e como ela foi gerada. É neste momento que extraímos mais informações dos especialistas de domínio para pensar na arquitetura de solução la na frente.

Falando sobre identificação do emissor do evento, temos algumas opções:

• Usuário - E aqui é importante saber que tipo de usuário (caso você possua mais de um tipo).
• Sistemas externos - Geralmente coisas que não estão na mão do time para resolver como por exemplo uma notificação de um gateway de pagamentos.
• Tempo - Ações que são disparadas em função da variável tempo como por exemplo uma enfermeira que de hora em hora precisa verificar todos os medicamentos que precisam ser administrados.
• Reações automáticas - Eventos que ocorrem em função de outros eventos ocorridos. Imagina que a farmácia do nosso hospital foi abastecida, logo preciso avisar a enfermaria para buscar os medicamentos faltantes.

Confesso que esse tipo de informação vai acabar tendo muito mais importância para o time técnico do que para o time de negócio, pois aqui podemos começar a pensar (não durante a cerimônia) em como modelar esses atores ai.

Além disso é importante identificar como os atores disparam esses eventos, se for um usuário pode ser através de uma interface por exemplo. Se for um sistema externo, pode ser uma API.

Reclassificação

Esta é a última etapa do trabalho. É o momento de organizar tudo novamente em uma sequência lógica/cronológica e é onde começamos a agrupar as coisas que começam a fazer mais sentido. Com a visão do todo, conseguimos agrupar os eventos/atores/comandos no que é chamado de Agregados.

Os agregados, de uma forma muito simplista, são entidades que possuem um relacionamento muito forte e que geralmente deveriam ser resolvidos em uma única transação. Saindo do nosso exemplo de hospital para uma pizzaria por exemplo. Um Cliente faz um Pedido com vários Ítens. Dificilmente, e agora partindo pro tecniquês, eu vou persistir as 3 entidades de uma vez só. Eu posso cadastrar só o cliente (com todos os atributos que o qualificam) e em um segundo momento, vou cadastrar o Pedido com seus ítens. Essa visão, nos faz chegar a conclusão que Cliente é uma agregado e Pedido (com seus ítens) é outro agregado.

E nesse momento senhoras e senhores, vem a cereja do bolo. Quando conseguimos identificar os agregados corretamente, podemos entender que cada um deles pode ser um módulo/microserviço na nossa arquitetura. O termo utilizado dentro do DDD para essa segmentação de agregados é conhecido como Contextos Delimitados (Bounded Contexts). Podemos interpretar isso como literalmente uma fronteira entre um microserviço e outro (caso seja a sua arquitetura referência).

E a arquitetura, fica onde?

Com a visão dos contextos delimitados e seus eventos, fica muito mais fácil desenhar uma arquitetura conectando as pontas. Na sua essência, os eventos (e aqui falando tecnicamente mesmo) são coisas que acontecem naquele contexto e que você precisa notificar para fora do limite em questão. Uma definição interessante para evento, na perspectiva técnica, é qualquer coisa que resulte em uma mudança de estado de um servidor. Alteração de dados cadastrais de um usuário, pagamento recebido, pedido criado, entrega efetuada e por ai vai.

Confesso que quando tive contato com Event Storm pela primeira vez, achei que seria uma volta muito grande pra desenhar uma arquitetura. Mas ai entendi, que o pulo do gato é que se eu fizer sozinho ou com pessoas que não conhecem o domínio, com certeza vou omitir comportamentos extremamente relevantes. E é nesse momento que os puxadinhos/gambiarras começam a acontecer.

Sobre o meu processo de aprendizagem

Comecei o artigo dizendo que não iria falar tanto sobre a técnica e mais sobre a minha preparação. Apenas para dar um contexto, eu ja sabia que a técnica existia mas nunca tinha me desafiado a facilitar/aprofundar no assunto. Nada como a boa e velha necessidade para fazer a gente sair da zona de conforto.

A necessidade aqui, saiu de uma discussão com o time de engenharia aqui da empresa sobre uma arquitetura que precisávamos refatorar para atender/corrigir novas nuances do negócio. Estávamos em quase 30 pessoas em uma sala, discutindo coisas e percebemos que não saímos do outro lado. Saímos com mais dúvidas que entramos e pra piorar, aumentamos desnecessariamente o escopo do problema (apontando comportamentos irrelevantes para o momento e não tendo profundidade sobre como tudo aquilo funcionava da perspectiva negociar).

Tentando entender quais os próximos passos, sugeri essa técnica de Event Storm ao passo que fui automaticamente indicado para puxar o tema. Sabem aquela frase famosa, toda pró-atividade será punida?? Brincadeiras a parte mas foi essa trucada que me forçou a estudar o tema mais a fundo. E confesso que sempre tive dificuldade de sentar e falar, vou estudar. Pra mim só ler ou entender como algo funciona não me gera conhecimento. Então separei o meu tempo para atacar alguns pontos:

• Recap sobre o tema - Aqui não teve jeito, a boa e velha leitura me ajudou bastante. Mas para não confiar demais só na minha cabeça, comecei a criar anotações com as minhas palavras e de forma que eu pudesse consultar durante o evento.
• Vídeos - Acho que aqui foi onde a minha mente abriu mesmo, porque uma coisa é ler alguns conceitos e alguns termos, mas outra é você vivenciar (mesmo como expectador) como tudo isso ocorre. E ai, consegui enriquecer minhas anotações mais ainda, com pontos que precisa lembrar durante a facilitação. E não to falando mal de tutoriais/artigos escritos não (senão nem estaria escrevendo um), mas ver as coisas acontecerem tiram algumas dúvidas que palavras não descrevem.
• Escrita - Sim, a escrita. Não minhas anotações para o dia mas esse artigo aqui. Um dia antes do evento, que eu ainda estava com bastante insegurança em puxar, durante o almoço me ocorreu que toda essa jornada poderia ser um artigo. E aqui está. Se você chegou até aqui, saiba que ele foi escrito antes do evento e praticamente todo em uma sessão só. Escrever me fez revisar alguns conceitos mentais e criar novos exemplos para cada etapa do processo.
• Conversas - Pensei algumas vezes se colocaria esse item porque não é o que parece. Como tudo ocorreu com pouco tempo, não consegui ter trocas com outras pessoas da empresa para fazer um double check, então eu conversei muito, mas muito mesmo, com a minha própria pessoa hahahahahaha. Sim, eu fui na padaria, na farmácia e mentalmente pegava um ponto que queria explorar e simplesmente começava a falar sobre. Acho que muita gente me achou no mínimo estranho na rua. Ja usei essa técnica quando precisei do meu inglês, imaginava uma pergunta aleatória e como responderia ela em inglês.

Conclusão

Provavelmente, se você está lendo esse artigo, é porque o evento foi no mínimo satisfatório. Não adianta eu esperar a perfeição (e me cobrar por isso), porque é a primeira vez que estou sendo exposto nesse desafio. Não posso exigir ter todas as respostas sobre a metodologia se eu não tenho experiência. Ao time que participou e me aturou por quase 2 horas falando e dando pitacos meu muito obrigado. Espero ter ajudado um pouco na treta que nos propusemos a resolver.

Edit 1: (Primeira atualização pós evento)

Pós evento e refletindo um pouco mais sobre o processo todo, algumas coisas que ja mapeei (e recebi de feedback) que poderiam ser melhoradas:

• Apesar do Event Storm estar diretamente ligado ao DDD, nem todo mundo que tava no papo tinha a mesma base de conhecimento sobre o tema. Talvez um nivelamento de conhecimento pode ajudar a evitar algumas dúvidas.
• Tempo, como ja previa não foi o suficiente (só tínhamos 2 horas). A última etapa não conseguimos rodar, mas esse é o problema mais fácil de resolver, acho que salvo raras excessões, no mínimo 3 horas são necessárias para não correr contra o relógio.
• A quantidade de pessoas presentes me surpreendeu (~25 pessoas), e apesar do que possa parecer não foi um caos organizar tudo isso. Mas talvez reduzir um pouco mais a quantidade de pessoas pode tornar o processo mais dinâmico. Muita gente participou como ouvinte mesmo ja que era muito novo ou realmente não conhecia do domínio.
• Trazer exemplos em cada etapa da dinâmica consegue dar mais segurança para quem vai participar. Uma coisa é explicar o que é um agregado da vida, mas outra é mostrar com fatos e casos de uso como que esse conceito se aplica.

Resultado até aqui: