Benefícios de utilizar Outcomes para definição de domínios do negócio (DDD) e como adaptamos essa prática na RD Station
Na minha última publicação sobre como fizemos a descoberta dos domínios (DDD) do RD Station Marketing através do EventStorming, eu mencionei como a decisão de utilizar Outcomes foi crucial para dividir o negócio em domínios. Não foi uma tarefa fácil, em um espaço curto de tempo tivemos que reprogramar a forma que pensamos sobre o produto. Para ajudar você a fazer o mesmo, vamos agora nos aprofundar mais sobre esse assunto:
Conceitos de divisão de domínios
Foco no problema x foco na solução
Direcionando o produto por resultados (outcomes)
Utilizando Outcomes para incrementar a estratégia de capítulos no EventStorming
Aprendizados
Conceitos de divisão de domínios
O Vaughn Vernon escreveu dois livros que nos ajudaram muito nessa jornada, o Domain-Driven Design Distilled e o Implementing Domain-Driven Design, e ambos dividem o domínio e subdomínios em espaço do problema e espaço da solução. Isso foi um divisor de águas, pois antes tentávamos tratar o problema e a solução como uma coisa só.
“Eu tenho algo a mais para lhe dizer sobre domínios. Eles possuem um espaço do problema e um espaço da solução. O espaço do problema nos permite pensar no desafio da estratégia do negócio a ser resolvido, enquanto o espaço da solução foca em como nós iremos implementar o software para resolver o problema do desafio do negócio. […]”
- Citação do Vaughn Vernon no livro “Implementing Domain-Driven Design” (tradução livre).
O espaço do problema é a combinação do Domínio Central (Core Domain) e os Subdomínios (Subdomains), que são definidos durante a exploração da estratégia atual do negócio. Os Subdomínios são importantes para identificar diferentes partes do domínio que são necessários para resolver um problema específico.
Já o espaço da solução possui um ou mais Bounded Contexts, que são um conjunto de modelos específicos de software. Para um mesmo problema existem várias soluções, e o Boudend Context é uma solução específica que é usada para realizar a solução como software.
Apesar de ser desejável ter uma relação um-para-um entre Subdomínios e Bounded Contexts, nem sempre isso é possível — principalmente quando o projeto já existe e do tamanho que temos. Então, o processo de descoberta é bem separado: primeiro se explora o espaço do problema, e só depois se inicia a exploração do espaço da solução.
A dinâmica do EventStorming Big Picture que fizemos aqui na RD Station foi focada apenas no espaço do problema, e conto a seguir como foi essa experiência.
Foco no problema x foco na solução
Imagine que você tenha o objetivo de ir de forma confortável e rápida ao seu trabalho diariamente, e você chega a conclusão que a melhor solução seria comprar um carro.
Após um tempo usando essa solução, ela começa a gerar problemas mecânicos e despesas financeiras, então você precisa parar para avaliar uma nova solução. Nesse momento é natural que sua cabeça comece a planejar a compra de um carro novo, afinal, essa solução funciona bem por um tempo, não é mesmo? E é aqui que perdemos o foco no problema e passamos a focar apenas na solução.
Isso acontece porque, na suposição acima, o carro é um meio para um fim, que é chegar de forma confortável e rápida ao trabalho. Se você focar no meio, você esquece do objetivo, que pode ter outros meios melhores para o momento atual. Você poderia, por exemplo, se mudar para perto do trabalho e ir de bicicleta (atualmente pode até escolher uma bicicleta elétrica!).
O seu projeto certamente não é o objetivo final do seu cliente, ele é um meio para ele atingir um objetivo específico. É muito fácil nos perdermos no caminho e ficarmos em um ciclo infinito de tentar arrumar e melhorar o que já existe, e então esquecer de procurar por novas soluções.
Mas não se engane, juntar várias pessoas em uma sala e pedir para elas focarem só no espaço do problema não é suficiente, pelo menos não foi aqui na RD Station. Era comum pensarmos nas funcionalidades do sistema como fim, e não como meio para o usuário realizar um objetivo. Foi então que entramos com o conceito de Outcomes para ajustar o rumo da dinâmica.
Direcionando o produto por resultados (outcomes)
No livro Introducing EventStorming, o Alberto Brandolini descreve Outcomes como o resultado de uma combinação de Eventos (Events) e Modelos de Leitura (Read Models), que podem ser divididos em “Sistema Feliz”, que é o estado em que nenhuma ação adicional é necessária, e “Usuário Feliz” para o estado quando os usuários envolvidos estão cientes da conclusão do processo.
Na dinâmica que realizamos aqui na RD Station, nós fomos além dessa definição. Nós também utilizamos o conceito de Jobs to Be Done, do Clayton Christensen, para identificar qual é a tarefa que o nosso cliente realmente busca realizar em cada etapa de sua jornada, com isso pudemos identificar o resultado (outcome) que oferecemos a ele.
Essa etapa de extrair os Outcomes foi a mais rica da dinâmica, pois gerou várias discussões sobre o valor que entregamos para os nossos clientes. Fizemos várias reflexões e construímos um entendimento bem mais sólido e alinhado com a estratégia do negócio.
Utilizando Outcomes para incrementar a estratégia de capítulos no EventStorming
Colocamos todos os Outcomes em cartões verdes no nosso quadro, depois copiamos todos para uma área vazia. Não tinham eventos, não tinham funcionalidades do sistema, não tinham dores dos clientes, não tinha nada além do trabalho a ser feito (job to be done), ou seja, o que o nosso cliente espera realizar usando o nosso produto.
Com uma área só com os Outcomes, passamos a agrupá-los em capítulos (chapters), de forma a fazer sentido em uma linha do tempo. O capítulo é uma das estratégias do EventStorming para ordenação dos eventos, mas não há muitos detalhes de como criá-los. Foi aqui então que os Outcomes entraram como peça chave desse quebra cabeça: utilizamos esse conceito para criar e ordenar os capítulos, e em vez de criá-los baseados nas tarefas, o foco estava em qual o objetivo a se atingir em cada momento dessa história. É uma mudança sutil na arquitetura da solução, porém que altera totalmente o resultado final.
Com os Outcomes devidamente organizados em Capítulos, utilizamos esse aprendizado para reordenar os eventos que foram definidos inicialmente, o que ajudou a balizar a discussão de onde elencar cada um deles em uma linha do tempo.
Aprendizados
- Tá tudo bem se perder durante o processo de ordenação dos eventos, o importante é ter pelo menos duas ou mais pessoas monitorando para poder interromper e trazer uma solução para resolver o impasse;
- Além da ordenação por capítulos (Chapter Sorting), existem outras estratégias como Pivotal Events, Swimlanes, Temporal Milestones e The Usual Suspects;
- Conduzir um EventStorming não é uma tarefa fácil, tão pouco é entender e aplicar o Domain Driven Design (DDD). Prefira escolher uma pessoa que já tenha experiência no assunto ou uma boa consultoria externa;
- Algumas pessoas vão ignorar as descobertas e rejeitar qualquer resultado diferente daquilo que elas já estão acostumadas (normalmente são aquelas que têm mais tempo na empresa), Brandolini classificou esse anti-padrão como “The Dungeon Master”. Por isso, é importante que as pessoas que liderem o trabalho, tenham mais autonomia do que elas;
- Abuse das analogias, das histórias e das explicações. A comunicação em todo processo precisa ser clara e fácil de ser entendida por todas as pessoas, afinal, as pessoas precisam entender o que está sendo feito para poder contribuir;
- Não se prenda a frameworks e metodologias, adapte as práticas de acordo com as necessidades do seu problema, negócio e produto. Aqui na RD Station, a nossa adaptação da metodologia tornou possível usá-la inclusive em outros contextos!
O que achou da forma como definimos os domínios de negócio aqui na RD Station? Caso tenha interesse em saber mais sobre como arquitetamos nossa Engenharia, leia os outros artigos em nosso Medium e confira as oportunidades de trabalho (100% remotas) que temos aqui dentro do time!
