[quote=Lezinho]Sergio, diferente do que você citou sobre as “práticas” utilizadas no XP e que o contempla, os padrões no DDD são apoios e não práticas necessárias.
Você utiliza Factory se precisar (vc poderia utilizar D.I.), utiliza Application Layer se assim fizer necessário (poderia utilizar um framework de abstração para esta camada), utiliza VO para maior flexibilidade do que uma entity desnecessária (mas não é estritamente necessário para a constituição de um DM).
Palavras de Evans sobre Domain-Driven:
(…)
… foco no conhecimento do domínio e de como espelhar sua complexidade entre “Domain Especialists” e o software, no lugar de se preocupar com arquiteturas técnicas e similares é o core do DDD, por isso a importancia do Ubiquitous sobre qualquer pattern.[/quote]
Tudo o que vc falou se aplica a qualquer metodologia de modelagem. Os padrões, quaiquer que sejam, sempre são usados quando necessário. “Domain Especilists” é apenas um nome para algo que sempre existiu. Outras metadologias dão outros nomes: por exemplo “stakeholders”. Não ha nada de novo em ter que falar com pessoas que entendem o dominio. E não ha nada de novo na necessidade de uma linguagem comum. Isso é o dia-a-dia.
Se o mérito da DDD é apenas chamar a atenção para a necessidade dessas coisas… bom, afinal não é muito mérito. É chamar as coisas com nomes bonitos e apresentar o óbvio.
Acho que a diferença fundamental entre a DDD e as outras metodologias de modelagem está no ponto de honra de colocar o desenvolvedor no mesmo patamar que o analista (aliás criando um hibrido). Ou seja, o cara que codifica é o mesmo que conversa com o cliente. Não ha intermediários. Não ha documentação “de tradução”. não ha perda (lost in translation) entre o que cliente “especilista” diz e o que o codigo faz.
Então a importancia do DDD está no facto do codigo também traduzir o dominio. Como diz a citação do Evans do artigo “dominio” é algo abstracto e está presente em muitos lugares de formas diferentes. Mas no fim, o que importa é que as interações entre os bytes mapeiem compreensivelmente as interações entre os atores , entidades e processos do dominio. Logo, a importância do DDD está no codigo ser uma reflexão do dominio. A complexidade da DDD é atingir esse introzamento entre o codigo e o dominio. O artigo parece defender que esse introzamento se limita a dar os nomes certos às classes… isso parece pouco.
Falar de DDD sem falar do codigo é insonso. Todas as outras caracteristias existem em outras modelagens. Ou vai-me dizer que em outras modelagem não se fala com os clientes ? não se cria um modelo ? não se usa uma linguagem comum ? As pessoas podem até estar menos consicentes de que estão fazendo isso, mas fazem.
A filosofia da DDD dá um passo à frente , e parece-me que foi esse passo em frente que não ficou explicito. Não foi dada a importancia necessária ao codigo. E mais, pelas respostas dos colegas do forum dá bem para ver que não ficaram satistifeitos só com aquele blablabla filosofico. O pessoal quer é codigo!
Falar de codigo não significa necessáriamente falar dos padrões , mas a menos que seja uma programação POG os padrões têm que estar lá. O que parece que falta entender é que não ha uma mapeamento 1:1 entre os padrões e as classes. Por exemplo, ninguem vai entender o que é uma entidade sem o conceito de identidade. A DDD diz que o dominio deve ser expresso em codigo. Então a pergunta que todos fazemos é : “Então, como se expressa em codigo ?”
Me lembro que a Revista Mundo Java, havia montado um Forúm, talvez em uma forma de questionar artigos e matérias, porém acho que o GUJ foi o que os consultores adotaram para um caminho com a cara do consultor java.