Storytelling de Domínio: Como isso pode salvar seu software

Introdução: O labirinto do DDD e os Livros Azul e Vermelho

Recentemente, terminei a leitura do livro Storytelling de Domínio (S. Hofer e H. Schwertner) [1]. Para quem está inserido no mundo do desenvolvimento, sabe que esse tema não nasce no vácuo; ele faz parte de um ecossistema muito maior e, por vezes, intimidador: o DDD [2] (Domain-Driven Design). Tudo começou lá atrás com o clássico de Eric Evans, o famoso "Livro Azul" [3] (Domain-Driven Design: Atacando as Complexidades no Coração do Software). Esse livro, sem exagero, mudou a forma como a indústria pensa a construção de sistemas complexos. No entanto, o Livro Azul é denso, quase filosófico em certas partes. Ele abriu portas, mas deixou muita gente perdida no "como fazer". Por conta dessa lacuna, anos depois, surgiu o "Livro Vermelho" [4] de Vaughn Vernon (Implementando Domain Driven Design), que trouxe uma pegada muito mais prática e "mão na massa".

O problema é que, para a maioria de nós, o primeiro contato com o DDD é enviesado. Quando ouvimos a sigla pela primeira vez, a impressão automática é: "Ah, é um padrão de arquitetura". Vemos cursos vendendo "DDD com Java" ou bibliotecas que te ajudam a implementar Domain Events [5] e Repositories [6] de forma rápida. De fato, muitos até no currículo colocam que possuem como skill técnica por exemplo: "Padrões de Arquitetura -> DDD, A. Hexagonal, Em Camadas, Microsserviços.". Mas aqui vai um "choque de realidade" que os livros Azul e Vermelho reforçam muito bem: reduzir o DDD aos Blocos de Construção ou o Aspecto Tático [7] do DDD é um erro crasso. O código, os repositórios e as entidades são a última parte de um processo muito maior. O aspecto tático é apenas o resultado final de uma jornada de descoberta.

O Domain-Driven Design é, antes de tudo, uma Metodologia de Negócio. É uma abordagem de ponta a ponta para softwares que estão "casados" com as regras de um setor específico. O DDD defende que deve haver uma aproximação constante entre os especialistas do domínio (as pessoas que vivem o processo no dia a dia) e os desenvolvedores. O pilar central disso tudo é a Linguagem Ubíqua [8]. Não é apenas "usar os mesmos nomes", é criar uma linguagem única e onipresente que elimine a tradução mental constante entre o que o cliente diz e o que o programador escreve. O objetivo é produtividade real nas duas pontas. O DDD impacta profundamente na forma como a equipe lida com a dor do cliente. Um desenvolvedor sozinho, isolado em sua sala, não tem o poder de implementar DDD, porque o DDD é algo intrínseco à cultura da equipe e da empresa. Se você acha que DDD é só estrutura de pastas no código fonte, você ainda não viu o quadro todo.

Na Prática: A Evolução do Quadro Branco do E. Evans até o Storytelling de Domínio

Eu sei que essa introdução foi longa, mas ela é essencial. Não existe Storytelling de Domínio sem o contexto do DDD. Eu quis evitar qualquer ruído, porque se eu não explicasse isso, você poderia achar que estamos falando apenas de "desenhar caixinhas". No Livro Azul, Eric Evans já defendia o uso de um quadro branco para conversar com os especialistas. Ele sugeria que o modelador deveria rabiscar, dar nomes e tentar extrair a lógica enquanto conversava. Mas o Evans não deu um "passo a passo" rígido de como essa conversa deve fluir. Ele apresentou sugestões baseadas no sucesso que teve em grandes empresas. Para ilustrar, temos diagramas clássicos que lembram o estilo do Evans (exemplo: Entregas com Drones, Figura 1), que são úteis (já são melhores que um UML), mas ainda não é a forma mais efetiva.

Figura 1 — Diagrama tático de DDD (estilo Evans). Fonte: learn.microsoft.com/pt-br/azure/architecture/microservices/model/tactical-ddd

O foco do Storytelling de Domínio é apresentar uma abordagem bem definida para esse processo de conversar com o especialista de domínio, que mais tarde se tornará a referência para a modelagem mais técnica e, por fim, a codificação do software pela equipe de desenvolvimento. Um software modelado corretamente é uma das chaves para resolver os problemas mais complexos do cliente. Se ruídos acontecerem (e eles vão acontecer), se os processos não forem mapeados corretamente, o software será implementado com esses ruídos (como observamos em diversos softwares legado, e até em alguns mais recentes); estou falando de impactos diretos na produtividade em menor ou maior grau, o que custa tempo e dinheiro. Mas atenção: o Storytelling de Domínio não é em si uma forma de levantamento de requisitos, mas ele vem para que o levantamento de requisitos seja feito de forma precisa e livre de "achismos" posteriormente.

Agora que você entendeu exatamente para que serve, vamos visualizar a diferença. A ideia de usar histórias é poderosa porque o cérebro humano é programado para elas. Nós lembramos de fábulas da infância, mas esquecemos de um relatório que lemos semana passada. Histórias carregam moral, lições e detalhes que estão nas entrelinhas. Humanos são, por natureza, contadores de histórias. Para provar o valor disso, eu mesmo fiz o exercício de modelar o caso dos drones utilizando o Storytelling de Domínio através do site Egon.io [9]. Ao seguir as setas numeradas, você entende a ordem dos acontecimentos.

Figura 2 — O mesmo caso ("Entregas com Drones") modelado com Storytelling de Domínio no Egon.io.

Confesso que ainda estou aprendendo, mas pergunto sinceramente: qual você consegue ler melhor? E, principalmente, qual o cliente conseguiria entender melhor? Qual diagrama o cliente poderia, com segurança, apontar erros no entendimento dos processos da empresa para a pessoa que estiver modelando? Para mim fica claro que o Storytelling de Domínio é visualmente superior para a comunicação porque ele não foca em "tabelas de banco", mas em "quem faz o quê, para quem e com qual ferramenta". E agora talvez você esteja se perguntando o que é esse "COMO ESTÁ" e "GRANULARIDADE FINA". Bem, esses são conceitos que o autor do livro usa, e é bem simples de entender.

Como Aplicar?

Para aplicar isso em um projeto real, seria necessário marcar reuniões presenciais ou on-line (o autor chama de Workshops [10]). Esqueça reuniões formais de terno e gravata; aqui o clima é de colaboração. Você convida os especialistas de domínio, também convidaria os desenvolvedores do projeto, para que eles ouçam o especialista falar e possam fazer suas anotações. É importante que haja diversidade na escolha dos especialistas e não somente pessoas da gerência da empresa. Se é um software para uma fábrica, por exemplo, é importante ter a visão da pessoa que está de fato no dia a dia, ou seja, no "Chão da Fábrica". A visão de quem aperta o botão é muitas vezes mais valiosa do que a de quem assina o relatório.

Uma vez convidados e todos comparecendo, é importante ter uma estrutura bem definida de conversa, então teremos um Moderador e um Modelador (responsável por fazer as perguntas e desenhar no quadro físico ou virtual; o Moderador pode ser um Modelador ao mesmo tempo), teremos os Ouvintes (geralmente os desenvolvedores) e, por fim, os Especialistas. Eles devem ser capazes de (com a permissão do moderador) contar a história de como é o dia a dia deles, um por vez, e em níveis de detalhes diferentes dependendo do momento, e é aí que entram as nomenclaturas:

• GRANULARIDADE GROSSA: os processos sem muitos detalhes. Nesse caso, queremos que o especialista nos conte uma visão geral; precisamos saber somente o essencial aqui.
• GRANULARIDADE FINA: um "zoom" em um processo específico. Nesse caso, queremos que o Especialista nos conte todos os detalhes, e o moderador deve ser capaz de extrair detalhes através de perguntas.
• COMO ESTÁ (AS-IS) [11]: o processo exatamente como acontece na atualidade, sem mudar nada, e de preferência até sem citar os sistemas que usam atualmente. Estamos atrás do DOMÍNIO PURO, sem a interferência de outros sistemas.
• COMO SERÁ (TO-BE) [11]: através da conversa com os especialistas, podemos mapear melhorias de processo, passos que podem ser otimizados ou automatizados completamente.

Todas essas informações, claro, não ficarão em um diagrama único, senão a complexidade seria impossível de administrar. O autor do livro recomenda que cada história tenha no máximo 20 figuras. Na história que eu fiz das Entregas com Drone, já estávamos em 9. E cada história deve ser documentada. Vale citar também que aqui estamos preocupados em mapear o Happy Path [12] corretamente, mas tendo os blocos de anotações para adicionar observações pertinentes. No Storytelling de Domínio também são proibidas condicionais. Imagine alguém contando uma história e de repente fala "Se eu fosse por esse caminho, tal situação aconteceria; se eu fosse por esse outro caminho, outra coisa aconteceria". Claramente a história perde fluidez. Os edge cases serão tratados em histórias separadas se necessário, ou então podem ser somente anotações fora da história. Nesse momento você pode pensar: "Então é só mais documentação". Bem, não tenho espaço neste artigo para te apresentar como o Eric Evans defende que o software seja documentado, mas te dou um spoiler: não é da forma tradicional. Para descobrir, leia o Livro Azul.

"E o resultado?"

No geral, as histórias de GRANULARIDADE GROSSA nos dão uma boa ideia dos CONTEXTOS DELIMITADOS [13] no Domínio do Negócio, o que nos dá pistas muito importantes de quando um departamento precisa conversar com outro, se há departamentos que estão isolados, entre outros casos. E as histórias de GRANULARIDADE FINA nos dão uma leitura de cada processo dentro da empresa. Além disso, também já temos grande parte da Linguagem Ubíqua pronta para ser utilizada entre a equipe de desenvolvimento e os especialistas no presente e futuro. Ou seja, o ruído de comunicação entre essas 2 pontas foi diminuído drasticamente. Especialistas de domínio e a equipe de desenvolvimento devem sempre conversar utilizando os termos da linguagem ubíqua, e caso em algum momento um termo parar de ser adequado para descrever qualquer um dos objetos ou agentes da história, o termo deve ser trocado em comum acordo por todos.

No fim das contas, o Storytelling de Domínio não é sobre desenhos bonitos, é sobre garantir que estamos construindo o software certo para o problema certo. É sobre transformar a confusão dos processos de uma empresa em uma estrutura lógica que o computador entenda, mas que o ser humano ainda consiga reconhecer como sua própria realidade. Se você quer elevar o nível do seu software e da sua equipe, pare de olhar só para o código e comece a ouvir — e desenhar — as histórias do seu cliente.

Notas de Rodapé

• [1] Obra principal que apresenta a técnica de modelagem visual através de ícones e atores para facilitar a comunicação entre negócio e tecnologia.
• [2] Domain-Driven Design: uma abordagem de desenvolvimento de software que prioriza o entendimento do domínio do negócio acima das ferramentas técnicas.
• [3] Referência clássica de Eric Evans (2003) que estabeleceu os princípios fundamentais do DDD.
• [4] Obra de Vaughn Vernon (2013) que foca na aplicação prática e técnica dos padrões do DDD.
• [5] Domain Events: eventos que representam algo relevante que aconteceu no domínio do negócio (ex.: "Pedido Finalizado").
• [6] Repositories: um padrão que abstrai o acesso a dados, tratando o banco como se fosse uma coleção de objetos em memória.
• [7] Aspecto Tático: conjunto de ferramentas técnicas do DDD (Entities, Value Objects, Services, Repositories) usadas para implementar a lógica.
• [8] Linguagem Ubíqua: um vocabulário compartilhado e rigoroso entre desenvolvedores e especialistas de domínio.
• [9] Ferramenta oficial de modelagem baseada em navegador para criar diagramas de Storytelling de Domínio.
• [10] Workshops: sessões colaborativas intensas onde o conhecimento é extraído através do diálogo e modelagem em tempo real.
• [11] AS-IS e TO-BE: termos de análise de processos que significam, respectivamente, "Como é" (estado atual) e "Como será" (estado futuro desejado).
• [12] Happy Path: o fluxo de execução de uma tarefa que não encontra nenhuma condição de erro ou exceção.
• [13] Contextos Delimitados (Bounded Contexts): fronteiras lógicas dentro de um sistema onde um modelo de domínio específico é aplicável e consistente.

Referências e Fontes

1. HOFER, Stefan; SCHWERTNER, Henning. Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software. Addison-Wesley Professional, 2021.
2. EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.
3. VERNON, Vaughn. Implementing Domain-Driven Design. Addison-Wesley Professional, 2013.
4. MICROSOFT. Tactical DDD (Diagrama Exemplo — Figura 1). Disponível em: learn.microsoft.com/pt-br/azure/architecture/microservices/model/tactical-ddd. Acesso em: 30 jan. 2026.
5. EGON.IO. Ferramenta de Modelagem Domain Storytelling. Disponível em: egon.io.