20 anos de DDD!

A virada do século foi realmente revolucionária na área da engenharia de software. Durante a década de 1990, várias correntes de Engenharia de Software se debruçaram sobre o tema da “Melhoria de processos”. Já tínhamos em curso várias melhorias, variantes do método cascata, buscando sempre entregar software relevante, no prazo e com custo executável.

Assim nomes famosos como XP Programming, SCRUM, Pair Programming, Refactoring e outros menos famosos como Crystal e FDD “competiam” no páreo da solução para a “Crise do Software”. Em 2001, as principais mentes pensantes da época se juntaram para pensar sobre o assunto. E assim nasceu o Manifesto Ágil.

Apenas dois anos depois, “resolvida” a “Crise do Software”, o mundo toma conhecimento da metodologia de modelagem de software proposta por Eric Evans: O Domain Driven Design. Rapidamente o “Livro Azul” tomou as prateleiras de todas as pessoas interessadas em software. E aquele que deveria se tornar a bíblia da modelagem de software, alçou estatus de glimório, tendo as suas palavras mágicas repetidas (como domínio e ubíquo), sem que se reflita muito bem sobre o que elas querem dizer.

E para entender essas palavras, primeiro é preciso lembrar como era o mundo em que DDD nasceu. O início dos anos 2000 era um mundo em que “nuvem” era apenas um sinal de chuva. E o deploy de software, geralmente, acontecia através da instalação manual via disquetes de 3 ¼ de polegada. Micro serviços? A primeira menção a micro serviço foi aparecer apenas em 2011, em um workshop para arquitetos.

Logo, quando lemos as palavras de Evans, precisamos compreender que é esse o mundo que ele tem em mente e que os problemas que ele pretende resolver, em grande parte, estão ligados a esse universo. Uma leitura sagaz desse conteúdo deve, portanto, portabilizar o âmago das soluções propostas pelo autor para o mundo que nos desafia hoje. É o que eu gosto de chamar (tomando emprestado o termo de outra área do saber) de “leitura histórico-crítica”.

Um outro ponto curioso que eu gostaria de ressaltar: Já reparou no currículo do Eric Evans, Vaughn Vernon, Eric Evans, Robert Martin, Alister Cockburn e tantos outros nomes que são signatários do manifesto ágil ou são autores renomados sobre DDD? O que eles têm em comum? São Arquitetos de Software!

Eu ainda sou do tempo em que a pessoa desenvolvedora acumulava todos os cargos. Era designer de produto e de serviço, era gestor de projeto, era customer success e suporte ao usuário. Lembro que a nossa briga, à época, era por não atender o telefone. Fazer o resto? Ok. Mas atender o telefone era a morte de qualquer projeto. E o divertido em se participar de vários projetos é que nós, desenvolvedores/as, nos tornávamos especialistas naquilo que desenvolvíamos (e por isso lidar com impostos sempre foi difícil pra mim).

Hoje os tempos são outros. As funções estão mais bem distribuídas. A área de “Engenharia de Software” está diluída nas funções de designer, arquitetura, desenvolvimento, coordenadores, analista entre outras. O que por um lado é bom, já que temos pessoas dedicadas e especializadas para cada etapa do processo. O que me incomoda é perceber que nós, arquitetos, estamos nos colocando cada vez mais distantes dos produtos e do processo de software em si.

Isso não seria um problema se a solução que desenhamos não fosse diretamente influenciada pela necessidade do cliente e pelas necessidades da gestão (tempo e custo). Ao passo que nos afastamos do produto, as soluções tornam-se mais abstratas e tendem a resolver um problema irrelevante para o usuário (olha a “Crise do Software” voltando aí), isso quando não criam um problema novo.

Agilidade e DDD (este principalmente) nascem para construir pontes entre o processo e a tecnologia. Uma ponte que existe para que ambos possam trafegar! Lembro de ler o livro do Evans e do Vaughn e ler coisas ousadas como “a pessoa de negócio deve ler o código e conseguir entender o processo que está sendo executado”.

Para que essa utopia seja alcançada, o arquiteto precisa conversar com os especialistas de domínio, ou seja: as pessoas que estão envolvidas no processo. Sejam elas da camada de gestão ou usuários do sistema. É impressionante o quanto é enriquecedora a experiência de saber como as coisas de fato acontecem in loco. Você observa os detalhes do processo, mas também fatores ambientais que podem explicar anomalias ocultas para quem se esconde atrás de um dashboard.

Outro ponto relevante nesses 20 anos de DDD são os processos de DDD.

Depois do encontro de Snowbird, inúmeras variações de agilidade surgiram – e ainda surgem. O mesmo aconteceu com DDD. Vejo cursos dizendo “como programar DDD”, onde instrutores confundem programação em camadas com DDD. Mas também é rico o número de processos, canvas, frameworks que criaram baseados em DDD e que buscam expressar do domínio do negócio.

E veja bem: Eu sou totalmente a favor de documentação e processos. Documentações nos ajudam a lembrar o que deveríamos estar fazendo. E processos empoderam pessoas a seguirem com o seu trabalho, sem precisar depender de consultar a gestão para saber qual o próximo passo. Mas eu me pergunto: Será que não estamos gerando tanta documentação, focando tanto em usar ferramentas e tão preocupados em seguir um plano, que estamos deixando de lado a resposta rápida a mudanças, os indivíduos e suas interações e principalmente: Software em funcionamento?

E mais uma vez, veja bem: Isso por si só não é um problema. Dependendo do projeto, realmente há mais ou menos espaço para erros (Crystal já pregava isso) e a necessidade de manter os stakeholders informados do “quê” e “como” está sendo feito. Tudo bem! Contudo, nesse cenário, abre-se mão de uma gestão ágil, uma vez que:

• Indivíduos e interações mais do que processos e ferramentas;
• Software em funcionamento mais do que documentação abrangente;
• Colaboração com o cliente mais do que negociação de contratos;
• Responder a mudanças mais do que seguir um plano.

É exatamente o texto do Manifesto Ágil. A riqueza aqui está em reconhecer exatamente o que estamos fazendo e por qual filosofia estamos nos orientando. Tendo isso em mente, buscaremos as respostas certas para os problemas corretos, sem enviesamentos desnecessários.

Por fim,

Domain Driven Design manteve a sua relevância ao longo desses vinte anos de estrada e transformações. No entanto, é preciso que se faça uma leitura histórico-crítica da metodologia, para que não se busque resolver problemas que não temos.

Outro ponto também é que metodologias como DDD servem para aproximar a área de negócio a área de engenharia de software. A engenharia deve ser capaz de modelar uma solução que seja compreensível e que reflita a necessidade do negócio. Qualquer coisa fora disso é desvirtuar a metodologia.

E para atingir essa “Babel antes da torre”, precisamos que todas as pessoas falem a mesma língua e compartilhem das vivências. Engenharia (aquela que é composta por designer, coordenadores, arquitetos, desenvolvedores e etc.) precisa ter um pé no produto e um pé no código.