Usando DDD e Event Storming para Remodelar o Domínio de um Módulo Legado

Published in

Involves Rocks

12 min readDec 19, 2017

Este artigo visa demonstrar como utilizamos a técnica de Event Storming para fazer o Domain Driven Design (DDD) de um módulo que estava sendo desacoplado do nosso monolito para uma arquitetura orientada a microservices. O artigo é intencionalmente um pouco mais longo que o normal pois pode servir como um guia reproduzível para quem pretende utilizar o Event Storming em seus projetos.

O Problema — The Legacy

Durante a manutenção ou criação de algumas funcionalidades em nosso monolito, tínhamos que despender um grande esforço para deixar essas funcionalidades compatíveis com o nosso sistema de controle de licenças e produtos contratados (base do nosso modelo de negócios). Os principais problemas eram que o código responsável pelo controle do licenciamento estava altamente acoplado com o código das funcionalidades propriamente ditas, a lógica utilizada estava bastante confusa e, por fim, não suportava a flexibilidade que precisávamos para evoluir o produto, pois para cada “upsell” que gostaríamos de testar/lançar em nosso produto, precisávamos dedicar um tempo maior de desenvolvimento para que ele fosse compatível com o sistema de cobranças.

Com isso, tínhamos duas possíveis opções na mesa: (1) refatorar o legado, cujo código possuía um enorme débito técnico, não estava contemplado com testes unitários e nenhum outro tipo de teste e, com isso, correr um grande risco de acabar lançando um pacote de bugs; ou, (2) aproveitar o esforço que estávamos tendo no sentido de desacoplar nossa arquitetura monolítica para uma arquitetura distribuída orientada a serviços (lê-se microservices e afins), recriando o módulo do zero, de forma desacoplada e aceitando o fato de que poderíamos levar um pouco mais de tempo de desenvolvimento para colher os frutos futuramente. Sensatamente, escolhemos a segunda opção.

A nova modelagem de domínio

A decisão de refazer a modelagem do domínio do zero também nos permitiria corrigir pequenos erros de design que cometemos durante o projeto inicial, o que não é incomum e pode ocorrer por diversos motivos, tais como: imaturidade no processo de análise de negócio, requisitos de negócios que evoluem de acordo com o tempo, velocidade que uma startup precisa dar inicialmente no desenvolvimento do produto para aproveitar o time-to-market, dentre outros.

Esse projeto acabou também nos levando a outros desafios. Um deles seria remodelar o domínio de forma desacoplada do monolito, já que o novo módulo rodaria em formato de microservice e isso exigiria um esforço ainda maior de modelagem. Isso pois, nesse estilo arquitetural, alguns dados não estão disponíveis de forma tão direta como estariam em uma arquitetura monolítica, conforme Christian Posta explica no artigo The Hardest Part About Microservices. Outro desafio que tínhamos era o de explicitar o conhecimento tácito sobre toda a complexidade do negócio (que estava na cabeça do PM e no setor de cobranças da empresa) para que todos os membros do time conseguissem ter uma visão abrangente sobre o domínio do negócio no qual iriam trabalhar. Por fim, essa remodelagem nos ajudaria a ter uma visão mais clara sobre o tamanho do problema no qual estaríamos embarcando.

Uma estratégia bastante comum utilizada para a modelagem de domínio, principalmente quando se trata de um arquitetura de microservices, é o chamado Domain Driven Design (DDD). Não está no escopo desse post explicar o DDD em detalhes, para isso você pode consultar essas referências Domain Drive Design, DDD Destilled e DDD — What is it and How do you use it?. Em resumo, o DDD é um conjunto de técnicas e ferramentas criadas e evangelizadas por Eric Evans que visam auxiliar desenvolvedores a criarem softwares que entregam mais valor por meio de uma representação mais precisa das necessidades de negócio.

O DDD é uma excelente escolha para auxiliar na modelagem do domínio em questão, mas implementá-lo não é algo tão trivial, pois envolve muitos conceitos diferentes, como Bounded Context, Ubiquitous Language, Entities, Aggregates, Domain Events, etc, e é comum olhar tudo aquilo, entender, mas não conseguir traçar um plano claro sobre como colocá-lo em prática. Para isso existe uma técnica que é muito menos comum e popular que o DDD, mas que é extremamente poderosa para esse fim, o Event Storming.

Event Storming

Event Storming é uma técnica de design rápido que engaja especialistas do domínio de negócios com desenvolvedores para que alcancem um ciclo rápido de aprendizagem (aprender o máximo possível no menor tempo possível), focando mais nos processos de negócio do que em abstrações técnicas (classes, entidades…).

O criador da técnica, Alberto Brandolini, fala sobre o formato do Event Storming em seu post de apresentação: Introducing Event Storming, como principais vantagens, posso destacar:

Acelera a aprendizagem de grupo, aprende-se em poucas horas o que geralmente poderia levar dias ou semanas
Promove o engajamento entre os especialistas de domínio e o time técnico
Ao final, é possível ter esboços do que serão futuros testes de aceitação, interfaces de serviços, atores envolvidos

Durante a realização do workshop, é bastante comum que as visões se alternem entre um nível mais detalhado de design, geralmente a visão do time técnico, e um nível mais abstrato, o que o autor chama de Big Picture, que é a visão dos especialistas de domínio.

Pré Event Storming

Antes de iniciar o workshop em si, fizemos o mapeamento de quais seriam os pré-requisitos e chegamos nos seguintes itens:

Sensibilização do Time de Desenvolvimento: colocar todos os membros do time técnico na mesma página, demonstrando o motivo da realização do workshop e quais seriam seus benefícios
Busca pelos especialistas de domínio: levantamento e sensibilização dos especialistas de domínio, nos mesmos moldes da etapa anterior
Agendamento do workshop: definição das datas e quantidade de sessões
Preparação do material: Canetas, post-its (laranja, azul claro, vermelho, amarelo claro, amarelo, rosa, verde) e um rolo de papel com 1 metro de altura e 10 metros de comprimento
Realização do workshop

Inciando o Event Storming

O Event Storming é composto por uma sequência de etapas pré-definidas, onde cada etapa procura adicionar mais detalhes ao modelo final. Inicialmente planejamos de 20 a 30 minutos por etapa, esse tempo deve ser controlado pelo facilitador. Também definimos que iríamos marcar com post-its vermelhos os pontos que gerassem algum tipo de indefinição e que necessitariam de um levantamento mais detalhado futuramente. Já com todos os detalhes acertados, colamos o papel na parede para deixar tudo pronto para o início.

Preparando para iniciar o Event Storming

Etapa 1 — Mapeando os Eventos

A primeira etapa do Event Storming consiste em mapear os eventos que ocorrem no domínio que está sendo estudado. Um evento é qualquer coisa relevante que aconteceu no passado e tende a ser de simples compreensão para pessoas não técnicas. Antes de iniciar essa etapa, traçamos uma linha horizontal por toda a extensão do papel na parede para indicar uma linha do tempo, assim ficaria mais fácil de entender em que ordem os eventos poderiam ocorrer, embora raramente a ordem deles fosse fixa na realidade.

Para essa etapa, utilizamos os post-its de cor laranja. O padrão para descrever o evento é utilizar o verbo no passado e deve-se tentar mapear todos os eventos que for possível nessa etapa, antes de passar para a próxima, entretanto, é comum descobrir novos eventos nas etapas posteriores, caso isso ocorra, não deixe de mapeá-los.

Alguns aprendizados sobre o processo que tivemos nesse etapa:

Encontramos um pouco de dificuldades iniciais para explicar o que é um evento para os especialistas de negócios (não técnicos)
Por se tratar de uma remodelagem, o software já existente acabou sendo bastante citado como base, coube ao facilitador tentar evitar que isso ocorresse
O facilitador deve cuidar para que, sem que percebam, os participantes fujam do escopo da etapa e comecem a citar o mapeamento das entidades ou regras de negócios
Acreditamos que foi a fase mais importante e esclarecedora. Permitiu que, a partir dos eventos identificados, todos discutissem mais sobre os processos que envolviam aquele evento, por isso essa etapa acabou levando 50 minutos, ao invés dos 30 inicialmente planejados
Conforme o planejado, marcamos com post-its vermelhos os pontos que vimos que deveriam ser detalhados com mais cuidado no levantamento das regras de negócio
Alguns exemplos de eventos identificados: Produto Ativado, Produto Desativado, Licença Utilizada, Licença Liberada, Novo Ambiente Criado

Etapa 2 — Identificando os Comandos

Com o mapeamento dos eventos finalizados, partimos para a segunda etapa, que era a identificação dos comandos que geravam os eventos. Geralmente os comandos estão associados à alguma ação do usuário, interação com sistema externo ou gerados por um temporizador/cron.

Nessa etapa utilizamos post-its de cor azul. O padrão de nomenclatura é a utilização do verbo na forma imperativa e ele deve ser colocado no lado esquerdo do evento que ele gera. Durante o processo, é comum identificar que um comando pode gerar vários eventos.

Alguns aprendizados sobre o processo que tivemos nesse etapa:

Como o previsto, alguns eventos que não tínhamos levantado na etapa anterior foram identificados nessa etapa;
Achamos que acabou sendo um pouco repetitiva, já que para a maioria dos eventos, bastava se basear no nome do evento e criá-lo no formato de ordem (imperativo);
Em alguns casos, foi possível identificar situações em que dois comandos distintos resultaram em um mesmo evento;
Foi uma etapa em que tivemos que decidir a granularidade do comando, entre big picture e visão detalhada, como o exemplo do comando “Ativar Usuário Válido” sem definir na modelagem os diferentes tipos de usuários válidos;
A partir dos nomes dos comandos, já foi possível ter uma breve ideia do que seriam os nossos endpoints de serviço das APIs que desenvolveríamos. Um dos devs até brincou: “Por que já não criamos os comandos no formato camelCase?”;
O facilitador novamente teve que cuidar para que a discussão não ultrapassasse o escopo da etapa e, ao mesmo tempo, para que detalhes importantes não fossem perdidos;
Novamente assinalamos em vermelho os pontos que vimos que deveriam ser detalhados com mais cuidado no momento de levantar as regras envolvidas em cada comando;
Alguns exemplos de comandos criados: Ativar Produto, Desativar Produto, Ativar Usuário Válido, Criar Ambiente, Desativar Ambiente, Reativar Ambiente.

Etapa 3 — Associando os Aggregates

Os aggregates são a parte do sistema que recebem os comandos e que geram os eventos, eles são os objetos que armazenam os dados e são modificados pelos comandos.

“É comum no ramo de TI iniciar a modelagem pelo diagrama ER ou de classes. Mas isso é um grande erro, uma vez que especialistas de negócio não entendem esse formato e podem encerrar a conversa a qualquer momento. Por isso o foco inicial do Event Storming é no mapeamento dos processos de negócio. O das entidades (aggregates) é deixado apenas para a terceira etapa” — Vaughn Vernon

Para essa etapa utilizamos post-its na cor amarela. Eles devem ser colocados acima e entre os pares de post-its comando/evento já mapeados e o padrão de nomenclatura é a utilização de um substantivo para representar o Aggregate. Para auxiliar, pode-se utilizar o nome entidade ou dado quando falar sobre Aggregate. Durante o exercício, pode ser que os Aggregates se repitam ao longo da linha do tempo, mas não se deve agrupá-los. A ideia é que o processo siga visível e demonstrando que ocorre durante um período de tempo.

Exemplo de Aggregate que mapeamos (detalhe para o post-it vermelho)

Alguns aprendizados sobre o processo que tivemos nesse etapa:

Nesse ponto alguns conceitos podem não existir na vida real (entidades formadas por associação entre entidades e complementadas por mais algumas informações);
Como o previsto, aggregates/entidades se repetiram durante o fluxo;
Na maior parte das vezes, é bastante intuitivo chegar ao aggregate a ser criado. Outras vezes é preciso quebrá-los em aggregates menores devido a complexidade;
Exemplo de Aggregates identificados: Produto, Ambiente, Contrato.

Com a etapa 3 finalizada, já tínhamos o principal entregável do Event Storming, que é o conhecimento sobre o modelo de domínio do negócio, com os Eventos, Comandos e Aggregates que fazem parte dele. Para ajudar a completar o trabalho, existem algumas etapas extras que podem ser seguidas, como a delimitação de domínios e subdomínios, identificação das possíveis Views do sistema e dos atores que executarão os comandos. Decidimos realizar apenas a definição dos domínios, deixando os demais levantamentos para uma etapa posterior do processo.

Etapa 4 — Delimitando as Fronteiras do Modelo e Identificando Domínios de Negócio

Após toda a discussão realizada no workshop, possivelmente já é possível identificar os prováveis domínios de negócio. Eles podem estar relacionados à divisões departamentais, diferentes visões que os especialistas do negócio possuem sobre o mesmo conceito ou, até mesmo, entidade que são importantes mas não fazem parte do Core do domínio. Também pode-se utilizar essa etapa para mapear eventos que “naveguem” entre os domínios e o sentido em que eles navegam. Assim é possível ter uma visão big picture sobre o fluxo dos processos.

Para realizar essa etapa, deve-se utilizar caneta preta, agrupar os itens que fazem parte do mesmo domínio e desenhar círculos para delimitá-lo. Também pode-se utilizar um post-it de cor diferente para dar nome ao domínio. Deve-se tomar cuidado pois a escrita com a caneta é permanente e pode não ser possível fazer a correção caso necessário. Devido isso, tomamos a liberdade de alterar o formato do previsto pelo workshop e utilizar um quadro branco para desenhar os possíveis domínios até que chegássemos a versão final.

Alguns aprendizados sobre o processo que tivemos nesse etapa:

As vezes pode não ser muito fácil delimitar um domínio devido ao grau de abstração que se tem. É importante a participação de desenvolvedores mais experientes que ajudem nas possíveis interpretações e na escolha da melhor opção;
Os Aggregates podem se repetir em diferentes domínios e o próprio DDD prevê algumas formas de tratar essas situações. O uso de consistência eventual e referenciar apenas pelo identificador o Aggregate, que também faz parte de outro domínio, são exemplos;
Deve-se deixar explícito também os contextos externos que podem fazer parte do domínio. No nosso caso tínhamos o contexto do Sales Force, CRM que utilizamos e que possui todas as informações sobre os clientes.

Após essa etapa chegamos ao final do workshop e percebemos o quanto a técnica foi interessante e eficiente para o que se propôs. Reunimos todas as informações levantadas e vimos que já era possível, com o que tínhamos, até esboçar o que seriam os possíveis microservices que teríamos que desenvolver e quais seriam os serviços que eles deveriam disponibilizar, conforme a imagem abaixo:

Key Takeaways

A realização do Event Storming nos permitiu:

Ter um ciclo rápido de aprendizagem sobre o domínio de negócio que iríamos trabalhar afinal, ao todo, o workshop durou um pouco mais de 3 horas;
Fazer com que especialistas de domínio e desenvolvedores falassem a mesma língua, fugindo de abstrações técnicas e focando em processos de negócio;
Criarmos um modelo final melhor e mais abrangente que o modelo legado que tínhamos;
Criarmos um esboço da arquitetura de serviços (microservices) que deveríamos desenvolver e quais os pontos de integração dessa arquitetura;
Um fato importante a ressaltar é que não é objetivo do Event Storming levantar em detalhes as regras de negócios envolvidas nos processos, isso deve ser feito posteriormente.