Anteriormente, vimos um pouco sobre o DDD e seus principais conceitos: domínios, subdomínios e bounded contexts. Porém, em situações complexas, pode ser complicado enxergar as fronteiras entre domínios, subdomínios e bounded contexts. Para auxiliar nessa missão, existe uma técnica que pode ser utilizada: trata-se do Event Storming.
O que é?
O Event Storming é um workshop criado por Alberto Brandolini. Ele visa facilitar a visualização de subdomínios e bounded contexts, além de auxiliar no processo de estabelecimento da linguagem ubíqua.
Vale ressaltar que o resultado de um event storming não é um diagrama de componentes ou de modelagem de dados, como o UML por exemplo. Muito pelo contrário: ele resulta em uma representação visual totalmente voltada aos comportamentos esperados do software.
Isso permite uma validação rápida e interativa deste modelo não somente pelo time de tecnologia, mas até mesmo por times de produto e negócio.
Como funciona?
A dinâmica do event storming visa reunir em uma sala todos os times envolvidos em um projeto, sejam estes times de tecnologia, de produto ou de negócio.
Através de uma dinâmica divertida e interativa, os times envolvidos passam a interagir para construírem uma representação visual dos processos e dos eventos que podem acontecer com o domínio a ser resolvido.
Este diagrama, que é construído em um quadro com canetas e post-its, acaba sendo construído em conjunto por todos durante estas interações.
Devido ao aspecto colaborativo, o event storming possibilita uma aceleração do aprendizado em grupo, onde o tempo necessário para criar um entendimento padronizado do domínio e dos aspectos de negócio é reduzido. No event storming, esse entendimento unificado dos aspectos de negócio pode ser atingido em questão de poucas horas ou dias.
Isso é certamente uma grande vantagem, já que as técnicas de modelagem mais tradicionais não conseguem um entendimento comum do domínio com tal rapidez.
O event storming também possui como missão fazer com que os times envolvidos descubram em conjunto a complexidade do projeto desde o início, ajudando a entender o processo de negócio. Consequentemente, os times em conjunto também podem pensar de maneira interativa em soluções para estes desafios antes mesmo de pensarem em tecnologia propriamente dita.
Para que o event storming atinja todos os objetivos, é importante reunir todas as pessoas do projeto neste workshop, principalmente os domain experts: são eles quem vão saber responder a maior parte das questões que surgirão durante este processo.
Para construir a representação visual obtida a partir do event storming, pode ser utilizado um mural grande ou um rolo de papel cobrindo boa parte da parede. Neste papel, as pessoas participantes podem ir colando post-its com cores diferentes, utilizando também canetas para realizar anotações e ligar estes post-its através de setas. Cada post-it possui uma cor específica e deve passar a ser colocado dentro do quadro em uma ordem específica, onde cada cor representa uma estrutura dentro do event storming.
A representação de cada cor bem como a ordem estão detalhadas abaixo:
• Post-its laranjas correspondem aos domain events: o primeiro passo no event storming é identificar os domain events. Um domain event é algo que acontece com os componentes de negócio e que tem significado de negócio. Por exemplo: em um sistema de pedido de comida por aplicativo, podem acontecer coisas após a confirmação de pedido, como a notificação do usuário por email de que o pedido foi confirmado. Nesse caso, pedido confirmado seria um domain event. Os domain events são importantes para entender como o software deve funcionar, além de ser mais fácil para os membros do projeto primeiro identificarem coisas que devem acontecer;
• Post-its azuis correspondem aos commands: como segunda etapa, podemos localizar a ação que causou cada um dos eventos de domínio. Estas ações são chamadas de commands. Os commands são escritos em post-its azuis e colocados antes do evento de domínio correspondente. Eles também podem ser interligados por setas, caso essa abordagem torne a representação mais clara. Commands geralmente representam interações do usuário com o sistema. No exemplo anterior, poderíamos ter o command “confirmar entrega de comida” que resultaria no domain event “pedido confirmado”;
• Post-its amarelos correspondem aos actors: commands geralmente representam uma interação de usuários com a aplicação. Estes usuários passam a ser denominados como actors dentro do DDD. No exemplo anterior, poderíamos ter um actor “gerente de restaurante” se ligando ao command “confirmar pedido”, command este gerando o domain event “pedido confirmado”;
• Post-its em amarelo claro representam os aggregates: commands e domain events podem ser agrupados dentro de grupos lógicos de acordo com o significado de negócio. Além disso, existirão estruturas do event storming que precisarão lidar com fluxos diferentes de maneira interligada. Estes são os aggregates. Em nosso exemplo, poderíamos agrupar todos os commands e domain events relacionados ao pedido de delivery de comida em uma grande unidade, pois seriam commands e eventos relacionados. Este grande grupo também precisaria de informações de várias entidades da aplicação, como as informações sobre os produtos, sobre o pedido e sobre os usuários. Neste caso, teríamos um aggregate;
• Post-its em roxo representam processes: processes são fluxos de negócio que podem acontecer em decorrência de um command ou mesmo como reação a um domain event. No exemplo anterior, poderíamos ter um processo de envio de email de notificação reagindo ao domain event “pedido confirmado”;
• Post-its em rosa representam external systems: um sistema externo é um provedor de serviços terceirizado, usado como solução para um problema no domínio, como um gateway de pagamento;
• Post-its em roxo ou vermelho claro representam policies: as policies (ou política) correspondem a validações que precisam ser realizadas dentro dos componentes do event storming. No exemplo anterior: poderíamos ter uma política atrelada ao command “confirmar pedido” indicando que o pedido só pode ser confirmado caso possua dois ou mais itens;
• Post-its em vermelho representam os errors: os errors correpondem a situações de erro que podem aparecer a partir de nossos commands ou policies. No exemplo, anterior, poderíamos ter o error “pedido possui somente 1 item” atrelado à policy “pedido deve possuir dois ou mais itens”;
• Post-its em verde representam as views: as views representam uma visão com a qual os usuários interagem para realizar uma tarefa na aplicação ou receber um feedback de alguma ação tomada.
Ainda levando-se em consideração o caso de pedido de entrega de comida, poderíamos ter o seguinte fragmento de um quadro do event storming:
Desta maneira, utilizar o event storming acaba nos trazendo uma melhor visualização e consequentemente, um melhor resultado.
