Senhores, segunda minha pesquisa enumero a baixo alguns problemas dos projetos que não usam DDD.
Oque vocês acham, precisa adicionar ou tirar algum item???
Comunicação Péssima entre programadores, analistas, Gerentes de Projeto e o Cliente, pois cada um tem o seu próprio vocabulário profissional e muitas vezes um não sabe o que o outro está falando exatamente.
Arquitetura focada em demasia na infra-estrutura, deixando de lado o mais importante que é a resolução do problema, assim teremos um aplicativo bom tecnicamente se for o caso, mas que não mas que não atende as expectativas do cliente.
Utilização errada do paradigma de programação orientada a objeto (POO).
Elevação desnecessária do grau de complexidade do software.
Sim claro, mas tirando os extremos, podemos afirmar que com o DDD a probabilidade de ocorrência dos itens que citei é menor?
Tem mais algum item que devo adicionar nessa lista? Ou preciso remover algum?
Não existe bala de prata. Não é um fodão chegando na equipe gritando “Vamos usar DDD!” que esses problemas que você citou irão desaparecer. Pra mim, DDD significa buscar um design que é a essência do negócio, nada mais. (Claro, alguns vão ter opinião diferente.)
Agora, as soluções para os problemas citados, estão longe de se resolver com DDD. Veja:
Porque a comunicação é péssima? Os funcionários estão localizados em regiões separadas? Existe muita burocracia? Criou-se uma espectativa para o cliente de que, basta um documento de 10 páginas e do outro lado sai um software certinho? Problema de comunicação se resolve investigando os problemas, perguntando pras pessoas… não aplicando uma solução mágica.
Porque se foca na infra-estrutura? Ela é complexa demais? É unica? Não é confiável? Além disso, as pessoas tem liberdade de fazer “refactorings”? Existe alguém se dedicando a isolar a arquitetura? Busque as respostas na sua equipe e resolva.
Por que se usa de maneira “errada”? É uma decisão consciente ou as pessoas fazem isso sem perceber (por falta de conhecimento)? Se for consciente, o não-uso de OO está sendo bom ou ruim? Se as pessoas não sabem OO, vale a pena ensiná-los? Busque as respostas e resolva.
Por que a complexidade é alta? Será que é por que problema a ser resolvido é complexo? Independente de for ou não for, existem formas de resolver? A causa da complexidade é ausência de conhecimento de negócio ou da tecnologia? Busque as respostas e resolva.
Por que a manutenção é custosa? As pessoas que estão mantendo são qualificadas? O software é problemático? É possível melhorar o software, mesmo que pouca coisa? Busque as respostas e resolva.
Por que existe retrabalho? Aliás, o retrabalho é ruim? Existem casos de testes (que minimiza os bugs antigos que são retornados)? O retrabalho é uma decisão consciente pra se fazer um melhor software, ou as pessoas estão patinando? Busque as respostas e resolva.
Existe na equipe incentivo a se fazer software de alta qualidade? Busque as respostas e resolva.
Isso é normal ou foi devido a um software mal feito? Existe incentivo na equipe a manter o sistema? O sistema tem conserto? Busque as respostas e resolva.
O que eu estou querendo dizer é que a solução de problemas precisa de uma investigação aprofundada na equipe. Se existem metodologias, elas devem servir como guias, não como bíblias. O fato é que muita gente não investiga a própria equipe, preferindo acreditar que a solução mágica vindo de um guru é a solução de todos os problemas.
Leonardo, entendo suas colocações, mas no seu ponto de vista em que o DDD pode ajudar um projeto?
Apenas para esclarecer, não procuro soluções mágicas para os problemas de um projeto de software, estou fazendo um projeto de pesquisa focado no DDD e estou trocando idéia nos fóruns enriquecer o trabalho.