Domain Driven Desing - Introdução

Após uma longa reflexão, decidi escrever esse artigo para compartilhar minha jornada de entendimento do DDD após alguns anos atuando como desenvolvedor de software. Lembro que em 2023, ainda como desenvolvedor júnior, comprei por recomendação de um blog o livro de Eric Evans e fiz minha primeira tentativa de leitura de Domain-Driven Design. Sendo bem honesto, foi bastante frustrante. Não entendi de fato a proposta do livro, meus olhos de iniciante procuravam formas práticas de implementar a metodologia em código, e muitos dos problemas levantados ali simplesmente não faziam sentido para mim naquela etapa da carreira. Anos depois, tirei o livro da estante e comecei uma nova leitura, agora com uma bagagem muito diferente. Para minha surpresa, finalmente entendi o que Evans queria dizer.

Tenho anos de experiência como professor, e durante essa segunda leitura percebi que o público-alvo do livro não são desenvolvedores no início de carreira, e sim pessoas que já enfrentaram os problemas que ele descreve: sistemas com contextos confusos, acoplamento desnecessário entre domínios de negócio, código que ninguém mais consegue explicar com clareza. O DDD não se trata de desenvolvimento de código propriamente dito, mas de intenção. A pergunta central que ele propõe é: "Essa interação pertence ao mesmo contexto no qual ela está inserida?" É um ciclo virtuoso onde o entendimento do negócio leva à definição de contextos, que resulta em código de melhor qualidade.

O primeiro passo para se aplicar o DDD é compreender o fluxo da operação: quem são os agentes envolvidos, quais são as etapas, onde cada responsabilidade começa e termina. Só com esse mapa em mãos é que faz sentido avançar para as duas lições mais valiosas do livro: a Ubiquitous Language e o Bounded Context.

Evans percebeu que o maior obstáculo para construir software de qualidade era a linguagem e quando me refiro à linguagem, falo de canal de comunicação. Durante minha jornada como desenvolvedor, não foi incomum perceber que muitos dos problemas que surgiam no processo de desenvolvimento eram resultado de comunicação imprecisa. Quando o mesmo conceito de negócio tem nomes diferentes dependendo de com quem você fala, fica impossível desenhar um projeto coerente. Por essa razão, Evans afirma que o primeiro passo do time, antes de pensar em qualquer solução a nível de código, é definir a terminologia do problema: desenvolvedores e stakeholders precisam conversar nos mesmos termos, com objetividade. Evans chamou isso de Ubiquitous Language — linguagem ubíqua.

Com a linguagem definida e o fluxo operacional compreendido, o próximo passo é identificar quais são os contextos de negócio presentes naquela operação. Esse mapeamento nos leva a outro conceito central do livro: o Bounded Context. O contexto delimitado permite que o desenvolvedor compreenda até onde uma determinada lógica pertence a uma operação, evitando que conceitos de contextos distintos se misturem e gerem exatamente o tipo de ambiguidade que o DDD se propõe a eliminar.

Este é o primeiro de uma série de três artigos. Nos próximos, sairemos da teoria e iremos a fundo em exemplos práticos, demonstrando como esses problemas aparecem nos sistemas que construímos todos os dias, muitas vezes sem nem percebermos.