Ep. 95 - DDD (Domain Driven Design)

Eu queria começar dizendo que essas três letrinhas que estão no nome desse episódio, DDD, elas surgiram pra mim em um momento em que eu estava estudando arquitetura de software. Código, muito código. Pra quem ouve o Love the Problem há algum tempo sabe que eu sou desenvolvedor de software, ainda sou, apesar de não fazer isso profissionalmente todo dia. E eu lembro que o paralelo que eu fazia era com outros padrões de arquitetura de software: eu já conhecia MVC, modelo em três camadas, e nem parei pra estudar DDD, porque achei que os padrões que eu já conhecia me bastavam.

E aí eu comecei a ouvir uma galera que não era de arquitetura de software falando sobre DDD. E eu pensei: pera aí, como assim, você não é de código, não é de arquitetura de software, e está falando de DDD? Tinha um negócio chamado Event Storming que eu não conhecia. Foi aí que percebi que não sabia nada sobre o assunto. Continuo não sabendo tudo, mas hoje vou saber mais, porque tem uma galera muito boa que anda praticando isso.

Hoje o assunto é DDD, Domain Driven Design, e para falar sobre isso convidamos três pessoas. Ana, UX designer na Thaler, entusiasta de DDD, que vem fazendo um paralelo entre DDD e UX desde que o Sebas apresentou o tema a ela no começo do ano. Sebastião Ferrari, o Sebas, CTO e cofundador da Thaler, empresa com quase dez anos de estrada, que traz o assunto a partir do trabalho que vem fazendo com o Rafa Cáceres e o Celso. E Alice, desenvolvedora na Thaler, também entusiasta de arquitetura, que já teve bastante experiência com levantamento de requisitos.

A última vez que eu tive contato com o DDD na prática foi em uma semana em que a gente estava rodando um serviço da K21 chamado Evidence, Extreme Value Driven Coaching: pega-se uma semana e fazem-se sprints diários com o time. De manhã, planning; durante o dia, todo mundo bota a mão no código ou no produto; no final do dia, review e retrospectiva. Isso todo dia. E como não dá tempo de fazer o mundo em um único dia, o Evidence acaba sendo um bom jeito de acabar com o Big Design Upfront: não dá pra fazer um design gigante quando você só tem um dia.

A gente estava num banco na Califórnia, rodando com dois times. Um deles tinha um problema clássico de produto no mundo inteiro: silos, ou seja, a galera que concebia as ideias do produto estava muito separada da galera que colocava a mão na massa para entregá-lo. No primeiro dia, perguntamos quem eram as pessoas que usavam o produto, quais os principais perfis de consumidores. Um dos devs respondeu que não sabia, e que não sabia por que estávamos insistindo naquilo, porque não era responsabilidade dele saber isso. Pedimos para ele ao menos arriscar um chute, só para começar de algum lugar.

Nesse momento ele disse que estava ficando irritado, que vinha de um fim de semana implantando sistema, e que agora estava sendo obrigado a pensar em quem usava o sistema dele. Levantou e saiu da sala. No dia seguinte nem foi trabalhar. Ficamos com a sensação de ter forçado demais a barra, e resolvemos aquilo conversando com ele depois.

No outro time o cenário era o oposto. O dev principal, o Steve, conseguia conversar sobre o problema que estava sendo resolvido e sobre quem usava o sistema de forma muito fluida. Em um dado momento ele trouxe uns diagramas parecidos com diagramas de classes, de modelagem técnica, e começou a discuti-los com a galera de negócio, que não manjava nada de técnico. Perguntamos o que era aquilo, e ele explicou que nas últimas semanas o time vinha fazendo dinâmicas usando DDD, e que aquilo tinha virado uma linguagem comum para conversar sobre o problema que estavam resolvendo. Perguntei que livro ele tinha lido, e ele respondeu: Eric Evans, e a partir daí comecei minha jornada para aprender sobre DDD.

Esses dois cenários mostram bem o problema dos silos: documentação sendo passada por baixo da porta, uma área concebe e joga para a outra implementar, sem diálogo real. E o cenário oposto, onde as coisas fluem porque existe uma linguagem e um entendimento compartilhados.

Onde o DDD se encaixa nisso? A primeira coisa é justamente reduzir os silos entre as áreas. O normal é separar as responsabilidades dos times de forma inconsciente, ou irresponsável para o bem do todo, e aí surge o "isso aqui não é minha responsabilidade". O papel de cada um não é só o como resolver o problema que chega pronto na mesa: o DDD ajuda a entender o domínio, ou seja, qual é o problema que de fato está sendo resolvido, para quem, em que contexto, com que nomes e que tipo de artefato resolve aquilo: manda um documento, assina uma newsletter, responde um quiz, faz um pagamento. Tudo isso são atividades que envolvem contextos, e são esses contextos que ajudam a criar entendimento das coisas que a gente vai modelando no código.

Uma prática que ajuda muito nisso é o Event Storming: trazer as pessoas certas no momento certo, em especial os domain experts, geralmente o cliente, o PO, ou alguém que vive o problema na pele. Um domínio grande pode ter vários problemas sendo resolvidos ao mesmo tempo, com várias perspectivas diferentes, e é através dessas perspectivas que se começam a criar narrativas. Essas narrativas viram historinhas que engajam as pessoas e contam o que acontece no dia a dia, como se resolve, como isso impacta outra pessoa em outra etapa do processo. Essa modelagem colaborativa é o que ajuda a tirar os silos.

O contraste é com o Big Design Upfront clássico: fechar arquiteto, UX e dono do projeto numa sala, produzir documentos de PPT que depois vão para o gerente de projeto operacionalizar. Nesse caminho se perde muito conhecimento, porque o único contato dos times de implementação muitas vezes é só com o designer, o gerente ou o PO, e aí já rola um filtro de informação que nem sempre reflete o que o cliente realmente quer. Em algum momento a gente é induzido a resolver o problema sem parar para perguntar: para quem estamos fazendo isso? Qual é o ator? Qual é o papel dele dentro do sistema?

Isso também explica por que a área de negócio às vezes nem entende o que os times técnicos falam: falta tradução. O que para um é "documento", para outro é "Node". Essa tradução muitas vezes não acontece bem, e isso tem relação com o conceito de injustiça epistêmica: uma pessoa não tem como explicar para a outra qual é a experiência dela, o que ela quer dizer, o que está acontecendo naquele momento.

Se o Love the Problem é sobre amar o problema, o problema que o DDD resolve é justamente saber qual problema a gente quer resolver. Dentro disso, o esforço de pessoas e mobilização busca sempre se aproximar ao máximo do domínio, e domínio, aqui, é território. Se a gente separar mapa e território, o software que vamos construir é sempre algo que ainda não existe no território e que desenhamos para passar a fazer parte da vida real. Quando falamos de domínio, estamos falando da vida real, e o esforço é aproximar a solução que desenhamos dessa vida real.

Do ponto de vista de quem já fez levantamento de requisitos "freestyle" antes de conhecer DDD: requisito já é uma palavra forte, porque parte da solução ("tem que ter isso") e não do problema. Antes, o levantamento era conversar com o usuário especialista e tentar trazer, muitas vezes, o próprio texto dele para um documento. O que muda com o DDD é a aproximação do cliente: ele participa com a mão no board junto, não é só ele falando e o time anotando.

O DDD também dá uma estrutura, não rígida, para explorar um mundo novo a cada projeto, mesmo quando os projetos parecem semelhantes. Isso dá respaldo para fazer perguntas, e conforme se entendem os eventos que vão acontecendo, coisas surgem mais facilmente. Outro ponto é conservar a linguagem do negócio dentro do time: cada funcionalidade desperta pontos e funções que serão desempenhadas no código, mas antes mesmo de entender o que o usuário espera do sistema já se corre o risco de já estar modelando banco de dados na cabeça, e essa é a etapa que precisa ser adiada.

O software não é um fim, é um meio para atingir o objetivo do negócio; focar só no código é se afastar do problema do domínio. O Alberto Brandolini tem uma frase que ficou marcada: o que é, no final, desenvolvido, é o entendimento do desenvolvedor, não é do PO, nem do stakeholder, nem do designer, mas sim de quem realmente vai fazer. Por isso é importante que todo mundo tenha um pleno entendimento de para quem, o que e por que se está fazendo algo, e esse entendimento não pode ficar limitado a quem cuida do design nem a quem cuida do negócio: qualquer pessoa envolvida no projeto deveria não necessariamente entender o problema por completo, mas aprender a questioná-lo, tomar conhecimento e desafiá-lo.

A última vez antes desse episódio em que se ouviu falar de DDD foi numa conferência chamada PLoP, Pattern Languages of Programs, onde um dos grandes divulgadores de DDD, Paul Rayner, falava sobre o assunto referenciando bastante um autor chamado Christopher Alexander, um arquiteto urbanista, não de software, autor de coisas tangíveis como casas e cidades. A pesquisa levou ao livro dele, "Uma Linguagem de Padrões", e as coisas começaram a se encaixar: a primeira impressão de que DDD seria "só" um padrão de arquitetura de software fazia ainda mais sentido ao ver que a própria referência do DDD vinha de um arquiteto que também escreveu sobre padrões.

O livro de Christopher Alexander traz padrões muito acessíveis, diferente da linguagem de arquitetura e urbanismo tradicional, pouco acessível a quem não estudou anos a área. Um exemplo é um padrão chamado, na tradução usada no episódio, "Janelas Voltadas Para Fora": o autor primeiro descreve o problema (ambientes sem vista externa funcionam como prisões para quem precisa ficar dentro deles) e depois propõe a solução, orientando a distribuir as janelas de cada ambiente de forma que a área total corresponda a uma proporção adequada da área do piso, posicionadas para captar as melhores vistas possíveis do que acontece lá fora. O padrão, mesmo tratando de arquitetura física, está o tempo todo se referenciando ao território, à vida real fora da construção, e é esse tipo de conexão entre a solução desenhada e a vida real que aproxima esse pensamento do DDD.

Do ponto de vista do design: pensar como alguém de UX no contexto do DDD é como pensar no papel do arquiteto urbanista dentro de uma obra, e a dev seria a engenheira dentro dessa mesma obra. A abordagem de UX centrada em seres humanos já parte de explorar os problemas do usuário através de uma imersão e análise cuidadosa do contexto, para extrair a solução a partir do questionamento intensivo do problema. Mas UX não deveria ser vista apenas como uma disciplina de design: mesmo num projeto sem design, que seja só código, existem pessoas por trás, e onde há pessoas há experiência, processos a mapear e oportunidades de melhoria contínua, que também é uma premissa básica de agilidade. O DDD encaixa como prato cheio para o UX designer justamente por abranger toda a cadeia de usuários, não só quem usa o produto final, mas todo mundo que passa por ali, desde a ideação e criação até o uso e a interação, cada um com uma percepção diferente sobre o mesmo contexto, percepções que não podem ser desconsideradas.

Uma diferença interessante entre o Human Centered Design e o DDD: no primeiro, você escuta para questionar, pergunta o porquê, a pessoa responde, e você segue perguntando os porquês, quase sobrepondo um saber ao outro, como se fosse necessário trocar uma experiência por outra. No DDD, escuta-se para abstrair: tudo fica no mesmo plano, tudo importa, e o processo fica mais colaborativo porque reúne a visão de várias pessoas com informações e saberes diferentes, atribuindo novos significados às mesmas coisas em vez de apenas ressignificá-las.

Essa ideia de abstração conecta com a arquitetura física: qualquer monumento, o MASP, a arquitetura de Brasília com o formato de avião, carrega uma abstração por trás, mas ela é um componente menos primário do que no software, porque o software é quase só abstração: código é um conjunto de abstrações sendo implementado. O DDD ajuda a identificar quais são os problemas mais importantes de forma mais sistêmica, por exemplo diferenciando tipos de domínio: o core subdomain é o que diferencia um negócio dos demais e o coloca no mapa do mercado; é ali que mais cuidado precisa ser dedicado aos nomes das coisas e aos contextos envolvidos, muito antes de qualquer discussão sobre banco de dados ou arquitetura de código.

Criar abstrações de forma prematura tende a gerar complexidade acidental, problemas que a própria modelagem cria e que depois vão exigir mais coisas para resolver. O DDD ajuda a entender qual é o nível de abstração necessário, o essencial para resolver o problema, nem mais nem menos. Isso tudo faz parte da chamada parte estratégica do DDD, que envolve diálogo e debate com quem vai usar o software e com o domain expert. A parte tática, por outro lado, é onde entram os padrões de arquitetura de software propriamente ditos, mais ligados à implementação. Na parte estratégica, quando surge uma palavra que a pessoa do negócio não entende, é preciso parar e explicar, e daí nasce um glossário, parte do trabalho de criar uma linguagem ubíqua.

No processo interno da Thaler para começar um projeto, existe uma modelagem de negócio e uma modelagem tech, e o DDD entra pesado justamente no overlap entre as duas: ali o time fala diretamente com o cliente para entender o problema, envolvendo UX, desenvolvimento e outras áreas, para colaborativamente entender o problema e modelar a solução. Do lado mais de negócio, conectam-se os problemas mapeados às soluções criadas, de forma colaborativa, com os objetivos de negócio e os impactos que se quer gerar, usando impact mapping para isso, combinado com event storming e context mapping. É dentro desse processo que nasce o glossário de conceitos: em um projeto de fintech, por exemplo, a quantidade de jargões do domínio é enorme, e cada termo, como "conta", que pode ser conta bancária ou conta de perfil de login, precisa ser contextualizado para fazer sentido. O context map ajuda a dar esse sentido, e o event storming é uma das maneiras de construir esse context map: um processo mais interativo, em estilo double diamond, que começa caótico, com muitos eventos, ações e contextos surgindo, e aos poucos vai revelando uma estrutura.

Não existe um "padrão de arquitetura do DDD" fixo: o time pode usar portas e adaptadores, arquitetura hexagonal, clean architecture, e cada projeto acaba ficando bem individual nesse aspecto. O que muda a chave de entendimento é aceitar que se está trabalhando com sistemas sociotécnicos: hoje praticamente tudo passa por algum sistema (pedir comida, achar um restaurante, tudo pelo celular), e isso significa que é preciso entender bem como acontece a interação das pessoas com esses sistemas: que termos usam, que conceitos, que atividades fazem e quando. É possível olhar para um UML e não fazer ideia de como se chegou até ali, sem o contexto que veio antes.

Também é importante ter uma visão sistêmica de quem está upstream e downstream: quem é impactado se a solução não for feita do jeito esperado, e como decisões tomadas no início do processo podem impactar etapas mais adiante. A segunda parte central é usar a emergência, deixar a estrutura emergir do caos ou da complexidade, em vez de simplesmente perguntar a stakeholders ou POs como o sistema deveria ser. É isso que o event storming faz, e há outras técnicas relacionadas ainda sendo estudadas, como o domain storytelling, para entrar em mais detalhes sobre como o processo funciona, quais artefatos e objetos de trabalho existem.

Comparando com outras técnicas de discovery, como Lean Inception ou Design Sprint: todas partem mais ou menos do mesmo princípio de questionar o problema e evitar apego prematuro à solução, com um ritual básico de fomentar ideias e gerar questionamentos. O DDD, porém, é o menos convencional dessas experiências, tanto ajuda a construir um novo olhar sobre um projeto já conhecido quanto coloca todo mundo na mesma página, independentemente do nível de saber de cada um. Isso reduz as camadas de "um sabe mais que o outro" e, consequentemente, as camadas de poder na tomada de decisão: fica mais fácil convencer um stakeholder que está acostumado a ter a última palavra, porque a abstração construída junto revela evidências que ele não costumava considerar, e ele passa a considerar outros pontos de vista.

Esse nivelamento acontece tanto na concepção quanto na construção: no exemplo do time da Califórnia, o dev que fazia boas perguntas participava das discussões de negócio, e a galera de produto também entrava nas discussões técnicas de modelagem, não ficava um grupo isolado falando sozinho com o outro. Quando chega a hora de tomar decisões de como fazer algo, fica muito mais fácil quando existe entendimento do que deve acontecer; essa relação entre o quê e o como vale tanto para decisões de design quanto de arquitetura, DevOps, código, testes.

Quando a modelagem é construída junto e vira código, há menos atrito para mudar o software quando o negócio muda, e isso tem um valor de negócio grande, ligado à própria ideia de agilidade: poder trocar de rumo, evoluir o software sem carregar abstrações desnecessárias. É comum olhar para um software legado, complexo, cheio de conceitos amarrados uns aos outros sem se saber onde termina um contexto e começa outro, um indicador claro de complexidade acidental. Isso importa especialmente para organizações grandes, times separados, modularização ou o mundo de microsserviços, que tornaram o DDD ainda mais relevante justamente porque exigiram limites claros de contexto: isso aqui resolve esse problema, não resolve outro.

Existe uma frase que resume bem essa relação: se você não entende o quê, o seu como vai sair torto. E o quê muda porque o porquê também muda, porque o mundo muda, e se essas mudanças não são entendidas, mudar o como fica muito mais difícil e complexo. Existe, claro, um nível de complexidade essencial em qualquer software, que não dá para descartar. O problema é discutir o como baseado em deduções pequenas, sem entender o quê nem o porquê. Um exercício ilustra isso bem: perguntar a um grupo se um valor deve ser arredondado para cima ou para baixo, receber uma resposta qualquer, e só depois de horas de desenvolvimento revelar que ninguém sabia sequer o que o sistema estava vendendo, e que a resposta certa dependeria completamente disso.

As necessidades também não são estáticas, nem do usuário nem da tecnologia, e a forma como essa modelagem acontece permite uma evolução mais gradual: não é preciso parar tudo para dar um passo atrás e rever; as coisas podem seguir andando e sendo revisadas em paralelo. Menos complexidade acidental, mais adaptabilidade, e agilidade, no fundo, é sobre ser adaptável.

Nas mensagens finais: o DDD traz a curiosidade de entender melhor como as pessoas interagem com o software, quando e por quê, e ajuda quem desenvolve a ter mais contato com quem está do outro lado. O desenvolvedor de hoje precisa sair da zona de só implementar requisito, sair do modo "tarefeiro", para se conectar com o objetivo de negócio e entender para quem e por que está fazendo algo.

Outro ponto que passou batido é a multidisciplinaridade: depois de mapear jornadas de serviço e validar com o cliente, a entrada no event storming trouxe contato com um livro, DDD Quickly, que traz duas ideias marcantes: um bom design acelera o bom desenvolvimento, enquanto o feedback vindo do processo de desenvolvimento melhora o design; e que refatoração feita por devs sem princípios sólidos de design produz código engessado e difícil de mudar. Combinar design com prática de desenvolvimento cria uma solução melhor, estreita a relação entre designer e dev, melhora a troca com o cliente e pode até sugerir novas ofertas de negócio, além de ajudar a criar não só uma linguagem ubíqua para o projeto, mas também uma linguagem ubíqua para o próprio time, o que fortalece a cultura.

No fundo, o DDD é uma cultura, uma forma de pensar o design. Para quem é dev e tem receio de tentar essa abordagem: no começo a cabeça vai puxar direto para o banco de dados, mas vale resistir: a recompensa compensa. Para quem é designer, vale o convite a se desafiar, ir além do que é ensinado no curso, porque isso favorece entregas mais relevantes: a vida é curta demais para fazer projetos sem sentido.

Christopher Alexander, a referência de arquitetura e urbanismo citada ao longo do episódio, persegue em seu trabalho um conceito chamado QWAN, Quality Without a Name, uma qualidade não nomeável. É possível fazer software sem entender os porquês, sem entender o domínio, o território, o negócio, dominando só a parte técnica; e é possível também entender bem a parte de negócio sem conseguir traduzir isso tecnicamente. Dos dois jeitos o resultado tende a não ser bom, e isso não se percebe olhando número de teste ou cobertura, mas pela sensação de entrar num ambiente, ou abrir um código, e se sentir bem ou mal. No fim, essa conversa toda gira em torno de perseguir essa qualidade sem nome: a sensação de que era exatamente aquilo que devia ter sido feito, algo com que dá para conviver, assim como uma casa ou uma cidade em que a gente se sente bem por fazer sentido para aquele contexto.