Modelagem e implementação com TDD e DDD

Segundo o livro The Passionate Programmer (Chad Fowler, 2009), uma das características mais importantes de um programador é sua capacidade de entender o negócio da empresa na qual trabalha (vide BOX 1).

Muitos de nós atuam profissionalmente no desenvolvimento de software em empresas que não têm o cerne do seu negócio em TI (como, por exemplo, no setor bancário, de seguros, de petróleo, etc.).

Não se trata, contudo, em ser um especialista em negócio (afinal, não é nossa profissão – como programadores, nosso trabalho é criar software), mas é importante que se conheçam os conceitos relevantes ao negócio e como os mesmos se relacionam, de forma a entender as necessidades dos clientes, abrindo caminho para a criação de um produto de software adequado.

Apenas ser especialista em tecnologia, num contexto como este, não basta: o programador deve entender o que o cliente realmente precisa e saber transportar esta necessidade para software.

A questão aqui é comunicação e entendimento. Ao conhecer o negócio da empresa, o programador está mais apto a entender, criticar e questionar requisitos e, posteriormente, a implementar software de valor.

Contudo, sabe-se que a falha de comunicação é um problema comum em desenvolvimento de software: o maior exemplo disto talvez seja aquele onde um mesmo termo é empregado com múltiplos significados (o que leva o dito por uma pessoa a ser entendido diferentemente por outra).

Desconsiderando o problema de comunicação por um momento, ainda resta a questão técnica de escrever software com base em conceitos do negócio. Existem tantas formas de se fazer isto quanto existem programadores – e nem todas as formas empregadas resultam em código-fonte legível, claro, extensível e testável, e que representa claramente o negócio da empresa.

No dia a dia, observa-se que dúvidas sobre as regras de negócio são repassadas para o código-fonte, o que resultará em problemas no futuro.

Por mais que um código-fonte esteja bem escrito, se os conceitos assumidos divergirem dos conceitos do negócio, problemas podem ocorrer por conta de dificuldades de comunicação e entendimento no que se espera que deva ser feito.

Neste contexto, as técnicas de modelagem e implementação que envolvem DDD e TDD podem ser empregadas em conjunto para lidar com os problemas de entendimento de negócio e representação adequada do mesmo em código-fonte Java com qualidade.

Conceituando o TDD enquanto ferramenta de design

A técnica de TDD (Test-Driven Development) é bastante conhecida atualmente pela sua característica controversa de escrever testes antes do código-fonte.

Ao se considerar o percentual de cobertura de código-fonte com testes como uma métrica de qualidade, TDD apresenta-se como uma forma eficaz de se programar.

Contudo, TDD também deve ser relacionado com design de software. O criador da técnica, em seu livro Test-Driven Development By Example (Kent Beck, 2003), aponta que as duas regras básicas do TDD (escrever código novo apenas quando o teste automatizado falhar e eliminar duplicação) levam a duas implicações em design: a) o design surge de forma orgânica, com código em execução provendo feedback entre decisões; e b) o design deve consistir em componentes com baixo acoplamento e alta coesão, para permitir que seja fácil testar.

Um design orgânico é aquele que surge conforme a aplicação evolui.

Este design é chamado de Evolucionário por Martin Fowler, e é caracterizado por ser parte do process ...