O maior desafio no desenvolvimento de software não é o código, é a comunicação

Depois de terminar o primeiro capítulo de Domain-Driven Design, de Eric Evans, iniciei a leitura do Capítulo 2, "Comunicação e Uso da Linguagem". Confesso que esse capítulo me chamou bastante a atenção, porque ele mostra que desenvolver software vai muito além de escrever código.

Eric Evans começa contando uma experiência real em um projeto relacionado ao desenvolvimento de placas PCI. No início, ele não possuía conhecimento suficiente sobre aquele domínio de negócio. Como muitos desenvolvedores fariam, poderia simplesmente começar a implementar requisitos técnicos. No entanto, ele percebeu que isso seria um grande erro.

A principal dificuldade não era tecnológica, mas sim entender a linguagem utilizada pelos especialistas do negócio. Engenheiros de hardware utilizavam termos específicos, conceitos próprios da área e uma forma de pensar completamente diferente da equipe de desenvolvimento. Enquanto cada grupo utilizava um vocabulário diferente, surgiam interpretações equivocadas, retrabalho e funcionalidades implementadas de maneira incorreta.

Foi justamente dessa experiência que surgiu um dos conceitos mais importantes do Domain-Driven Design: a Linguagem Ubíqua (Ubiquitous Language).

O que é a Linguagem Ubíqua?

A Linguagem Ubíqua consiste em criar um vocabulário comum entre desenvolvedores, analistas, especialistas do negócio, clientes e demais envolvidos no projeto.

Essa linguagem deve aparecer em todos os lugares:

• nas conversas da equipe;
• nas reuniões;
• na documentação;
• nos diagramas;
• nos nomes das classes;
• nos métodos;
• nas APIs;
• no banco de dados, sempre que fizer sentido.

Quando todos utilizam exatamente os mesmos termos para representar um conceito do negócio, a comunicação melhora significativamente e as chances de erro diminuem.

A tecnologia não resolve um problema de entendimento

Outro ponto que considero muito interessante é que Eric Evans deixa claro que nenhuma arquitetura sofisticada, framework moderno ou linguagem de programação consegue compensar uma equipe que não entende o domínio do problema.

Podemos utilizar Laravel, Symfony, .NET, Java ou qualquer outra tecnologia. Se não compreendermos o negócio que estamos modelando, dificilmente construiremos um software que realmente entregue valor.

Minha reflexão

Enquanto lia esse capítulo, lembrei imediatamente dos projetos corporativos nos quais participei.

Em sistemas ERP, e-commerce B2B, logística e gestão comercial, é muito comum encontrar palavras que possuem um significado muito específico para aquele negócio. Quando o desenvolvedor interpreta esses termos de maneira diferente dos usuários, surgem bugs que, na verdade, não são erros de programação, mas erros de entendimento.

Percebo que muitas vezes nós, desenvolvedores, temos a ansiedade de começar a codificar rapidamente. Entretanto, talvez o melhor investimento seja gastar mais tempo conversando com quem realmente conhece o negócio.

O maior aprendizado deste capítulo

Se eu tivesse que resumir o Capítulo 2 em apenas uma frase, seria esta:

Antes de modelar o software, é preciso modelar a linguagem utilizada pelas pessoas que entendem o negócio.

Esse conceito parece simples, mas muda completamente a forma como enxergamos o desenvolvimento de sistemas. O código deixa de ser apenas uma implementação técnica e passa a representar, de maneira fiel, o conhecimento do domínio.

Estou gostando bastante da leitura do Domain-Driven Design. Mesmo sendo um livro publicado há muitos anos, muitos dos problemas descritos por Eric Evans continuam extremamente atuais. A impressão que tenho é que os projetos de software falham muito mais por problemas de comunicação do que por limitações tecnológicas.

Estou ansioso para continuar a leitura dos próximos capítulos e compartilhar aqui os principais aprendizados.