Domain-Driven Design é um tópico recorrente hoje em dia. Dada a popularidade do assunto em fóruns e a frequência da lista de discussão percebe-se que há muita gente interessada no assunto. Gostaria de aproveitar a oportunidade para opinar sobre o cenário que eu considero mais apropriado para rodar um projeto DDD.
Primeiro é necessário um processo de desenvolvimento que contemple práticas da engenharia de software como design evolutivo e testes automatizados. Testes fornecem a segurança necessária para lidar com as inevitáveis alterações nos requisitos e as correções de rumo motivadas por novas revelações sobre o domínio. Além disso considero importante que o código reflita o modelo sem impor obstáculos ao entendimento do domínio por parte dos analistas de negócio; e se eles não forem capazes de entender este modelo é porque têm algo de errado com o modelo! O uso consciente de frameworks técnicos aliado a uma arquitetura em camadas permitem diminuir o gap entre modelo (domínio) e implementação (código) criando um design que modela simplesmente o domínio. No entanto, a diversidade de opções de frameworks disponíveis e a necessidade de treinamento nessas ferramentas fazem da busca pelo cenário que eu considero ideal o primeiro desafio.
Uma metodologia de desenvolvimento ágil e uma plataforma capaz de libertar o domínio da infraestrutura técnica é apenas o setting que eu acho mais apropriado. Mas DDD é acima de tudo uma especialização do paradigma de desenvolvimento de software baseado em modelos (MDSD) cujo approach consiste na definição de uma linguagem comum de negócio e em técnicas de implementação que permitam o modelo ser expresso diretamente no código.
Em relação à atribuição de responsabilidades na equipe eu considero um anti-pattern para projetos DDD a forma como ela é feita nas softwarehouses, onde os melhores técnicos são alocados na construção de frameworks caseiros enquanto o domínio carece de bons modeladores. Pelo fato de não interessar especializar-se no domínio do cliente este modelo falha ao privilegiar a melhoria do seu processo interno em detrimento à essência do domain-model, que é o business asset do cliente. Na minha opinião treinamento interno de pessoal e/ou consultoria alocada diretamente no cliente funcionam melhor do que fábricas de software para a modelagem de domínio.
