Como fazer Event Storming —Introdução
Olá pessoal gostaria de falar um pouco do processo que adotamos ao “separar” domínios e criar software que faça sentido.
Nosso grande desafio tem sido conseguir extrair a linguagem dos especialistas em domínio. Existem algumas técnicas que podem facilitar o processo. Ultimamente temos usado uma que se encaixou melhor com a nossa realidade que é o Event Storming inventado por Alberto Brandolini. Para saber mais você poderia ler o livro de Alberto que está em processo de conclusão.
Falando um pouco sobre o Alberto ao criar o Event Storming ele utilizou o Princípio de pareto o famoso termo 80/20 (80% de ganho com 20% de esforço), o conteúdo atual de seu livro é suficiente para ter a ideia e realizar a técnica. Claro, que para isso é necessário estudar um pouco porque não é tão simples assim. Além disso, Mariusz Gil possui um excelente repositório dedicado ao tema. Este repositório do Git tem um grande material sobre Event Storming.
Li o livro de Alberto e participei de alguns workshops conduzidos pelo Thiago Bustamante. Agora começei a conduzir minhas primeiras sessões usando a Event Storming. Gostaria de compartilhar um pouco do conhecimento que obtive nas últimas semanas.
Gostaria de acrescentar que uma ótima ferramenta para realizar o processo tem sido o MIRO.
Objetivo
Apresentar o que é Event storming, em que cenários utilizar, como utilizar, e o passo a passo.
Ao final do Event storming, teremos um output, que pode ser utilizado para desenhar e arquiteturar os seus microserviços.
O que é Event Storming?
Event Storming é uma maneira colaborativa, prática e hands-on de apresentar todos os eventos do sistema, para que tanto pessoas de negócio quanto pessoas técnicas possam entender.
É poderoso : permitiu que eu e muitos profissionais apresentássemos um modelo abrangente de um fluxo de negócios completo em horas, em vez de semanas.
É envolvente : a ideia é trazer pessoas com as perguntas e pessoas que sabem a resposta na mesma sala e construir um modelo juntos.
É eficiente : o modelo resultante está perfeitamente alinhado com um estilo de implementação Domain-Driven Design (particularmente adequado a uma abordagem de Event Sourcing) e permite uma determinação rápida dos Contextos delimitados e Agregações.
É facil: a notação é ultra-simples. Nenhuma UML complexa que possa isolar os participantes do centro da discussão.
Ator (User)
Representação: pequeno sticky notes Amarelo.
Uma pessoa que executa um comando por meio de uma visão.
Abaixo um fluxo disparado por um ator:
Comandos (Command)
Representação: sticky notes Azul claro.
Comandos representam uma ação, interação ou decisão que leva ao evento com o qual está relacionado. Considere que é algo realizado por um usuário ou sistema externo.
Exemplos de comandos:
· O sistema externo ”Seguradora” envia um comando para ”Empresa X”.
Podemos representar o ator que disparou o comando para esclarecer as responsabilidades.
· O assessor é o ator responsável pela criação da proposta
Segue abaixo a visão geral de sistemas externo, comandos, eventos e atores interligados:
Como conduzir esta seção?
1. Analise todos eventos que já adicionou no board
2. Adicione o sticky de comando ao lado esquerdo de cada evento existente
3. Descreva os comandos com verbos transitivos, como exemplo: Criar, Deletar, Enviar, Transacionar, etc.
Evento (Domain event)
Representação: sticky notes Laranja.
Os eventos são atividades que precisam acontecer dentro da nossa solução final. Isto quer dizer tanto as já existentes quanto novas no sistema proposto.
Por convenção, os eventos são conjugados no passado, como por exemplo: Proposta Criada, Apólice Emitida, Cadastro Criado, Pagamento Criado, Pagamento Finalizado, Usuário Cadastrado e etc.
Como conduzir esta seção?
1. Pergunte ao grupo quais eventos existem na sequência do fluxo do seu processo.
2. Pergunte ao grupo quais novos eventos deveriam existir no processo.
3. Ordene os eventos numa linha do tempo de acontecimentos. À medida que evoluir com os eventos, verifique se é preciso reordenar. Com o fluxo mais claro, a tendência é o grupo lembrar dos eventos que ainda não colocou.
4. Identifique eventos que ocorram em paralelo. Neste caso, ao invés de colocar na sequência da linha do tempo, coloque-os um abaixo do outro, indicando assim o paralelismo dos eventos.
Evento Disparado por tempo (Time triggered Event)
Representação: sticky notes Laranja.
Durante as sessões de event storming, podemos ter o cenário de steps que precisam acontecer, que são disparados pelo tempo, e não por ações, interações com usuários ou software.
· Evento “Proposta pendente há mais de 10 dias” disparado por tempo pré definido (ex.: job que faz polling na base de proposta)
Exemplos práticos:
· Evento disparado pelo job de alguma ferramenta de agendamento.
· Evento disparado por ETL do banco de dados.
Como conduzir esta seção?
1. Pergunte ao time se existe algum evento que é disparado sem nenhum usuário ou sistema envolvido.
Questões (Concern)
Representação: sticky notes Rosa.
Na medida que avançamos em nossa definição de eventos, podem surgir dúvidas ou preocupações sobre um determinado evento. Pode também existir algum termo que é específico do negócio e é válido criar um glossário com as definições destas terminologias. Para evitar este travamento, devemos destacar tudo no board e continuar com a sessão.
Exemplos: “Como será tratado o fluxo de erros?” ou “O que acontece caso um serviço estiver inativo?”, ou simplesmente alguma nota explicando algo.
É uma convenção colocar estes pontos de atenção acima dos eventos.
Como conduzir esta seção?
1. Crie uma área no board com o glossário dos principais termos de negócio
2. Peça ao time para colocar em ordem de prioridade as dúvidas/preocupações da esquerda para a direita
3. Esclareça com o time cada termo ou evento que gerou dúvidas
Políticas (Business process)
Representação: sticky notes Roxo.
As políticas indicam a decisão a ser tomada, que dispararão novos comandos e eventos. Ela é um processo decisório do fluxo.
· Derivação de fluxo em caso de Mercado aberto ou fechado
· Com mercado aberto, derivação de fluxo de acordo com o tipo da ordem enviada
Como conduzir esta seção?
1. Pergunte ao time quais processos decisórios são consequências de cada um dos eventos no board.
2. Adicione o relacionamento da política ao elemento correspondente ao ponto onde se faz necessária a decisão de negócio
Sistema Externo (External system)
Representação: sticky notes Rosa claro.
É possível que exista dependência com sistemas externos para gerar uma ação ou comando no sistema. Sistemas externos pode ser qualquer coisa que o time não tenha controle.
Exemplo de um sistema externo executando um comando:
Como conduzir esta seção?
1. Pergunte ao time se existe dependência com algum sistema externo para consulta ou execução de ação/comando.
Modo Leitura (View)
Representação: sticky notes Verde Claro.
Nesta etapa do event storming, identifique todos os pontos do sistema onde é necessário dispor de uma interface para consulta de informações.
Pode ser qualquer parte de uma interface do usuário ou registro de informações que o usuário precisa para tomar uma decisão ou executar uma ação.
Exemplo de Uso:
Como conduzir esta seção?
1. Pergunte ao time se existe/existirá alguma tela para consulta
2. Pergunte ao time se existe/existirá um push de notificação
3. Pergunte ao time se existe/existirá um relatório gerado por seu sistema
4. Pergunte ao time se existe/existirá uma consulta SQL
Agregação (Aggregate)
Representação: sticky notes Amarelo Claro.
As agregações são conjuntos de dados (Entidades e Value Objects) que estão relacionadas e que podemos ver como uma unidade.
Descrevemos as agregações usando um substantivo e as representamos com um sticky note no topo do fluxo e uma elipse delimitando os eventos, comandos e demais elementos que com ela se associam.
Desta forma, nesta etapa reunimos pares de comandos e eventos com outros pares de comandos e eventos que atuam nos mesmos dados.
Exemplo de uma agregação completa:
Caso tenhamos eventos que se originam associados a outras agregações, podemos colocar um pequeno sticky note com o nome da agregação de origem próximo ao evento.
Agregação “Boleto” indica o conjunto de dados que o fluxo acima vai resultar.
O Evento “Pagamento Criado” se origina na agregação “Pagamento”.
Como conduzir esta seção?
1. Conecte os eventos/comandos às agregações
2. Defina o nome da agregação utilizando um substantivo que descreva os dados contidos no conjunto
3. Dentro de um boundary (vide abaixo) não deve existir duas agregações com o mesmo nome
Boundaries
Representação: Retângulo com borda preta tracejada
Os boundaries ajudam a identificar as agregações correlacionadas dentro do mesmo contexto.
No exemplo abaixo, todas as agregações estão limitadas dentro do contexto chamado “Pagamento”.
Como conduzir esta seção?
1. Identifique as agregações que estão correlacionadas
2. Utilize o retângulo preto tracejado para delimitar os conjuntos de agregações
Bom espero que o conteúdo seja útil, vou ficando por aqui.Até a próxima
