O que caracteriza o termo "Sindrome de DAO" frente ao Domain Model?

É Márcio, todos nós já percebemos sua admiração pelo Sérgio :lol:

Pra ser bom , a gente tem que seguir os melhores ahahh !!! :lol:

"Repositórios: pra que te quero?

Domain-Driven Desing não é sobre padrões - isso gera muita discussão. Domain-Driven Design (ou simplesmente DDD) é sobre fazer software de maneira mais simples - e sei que muitos não vão concordar com isso, pois ?parece? que é mais fácil e muitos se sentem muitos produtivos ligando Table Modules diretamente às telas e abusando de Transaction Scripts.

O objetivo deste artigo não é falar sobre o que a literatura diz sobre repositórios e nem tenho a pretensão de escrever o ?post definitivo sobre Repositórios?. O objetivo aqui é demonstrar como tenho aplicado Repositórios nesses 3 anos de experiência em aplicação e ensino de DDD."

DDD não é exatamente sobre fazer software mais simples, mas modelar o software de forma a melhor expressar o conhecimento sobre o problema em questão. O resultado final de todo software bem projetado e o melhor entendimento por parte de quem for dar manutencao, mas isso não significa que o processo pra chegar ate esse ponto foi mais simples, muito menos que foi mais fácil, doque produzir código anêmico.

Como sempre, taborda falou falou e não disse nada. Agora me diz, o que um programador java inexperiente tira de conclusão desses artigos? Nada, ele vai continuar usando DAO em tudo sem saber o que, para o autor, é um DAO e o que o diferencia de Repositories e semelhantes.

Ser semelhante não quer dizer que tenha a mesma funcionalidade, como eu coloquei existe ai uma questão que nem mesmo aqui ninguem conseguiu aproximar uma conclusão, não vejo você fazer qualquer observação que faça justificar o seu uso devido.

Como observei não acredito que seja uma questão ao uso, é uma questão de não saberem o que é design sobre Orientação a Objetos e sobre onde determinado Dominio justificaria o uso para identificar o DAO ou Repository no mecanismo de persistencia.

DDD é nada mais nada menos do que programar Orientado por Objetos corretamente, no caso do JAVA usá-la da maneira como ela foi feita pra ser usada, ou seja, OO!

Discordo. Pra mim são coisas complementares. Enquanto OO é sobre atribuir responsabilidades aos objetos, DDD é mais sobre interação com analistas de negócio para descobrir quais são essas responsabilidades.

hehe… semelhante aos textos do shoes…

Eu ainda quero saber em que empresa troca-se tanto o meio de persistência dos dados… :roll:

Finalmente um comentario pé no chão… parabens Vini…

Cara… engo quer abstrair o abstrato… já poem JPA que é para astrair bem as coisas e vem em cima e joga OUTRA camada de abstracao…

To comecando a acreditar na piada do principe utilizando JAVA para matar o dragao…

tu é paga pau desse sergio heim…

“Levanta a mão pra deus e agradeça, que existem pessoas que lhe expliquem, o que você não exerce de conhecimento”

Eu sinceramente acho esse negocio de DDD um bafafá danado… eh que nem a tal da DSL , rapaz… eu realmente gostaria de ver um sistema que REALMENTE usa-se uma DSL… prq nego fala , fala ,fala e na hora de implementar… cade ? faz um enjambre e chamda de exemplo…

DDD é outro… milhoes de artigos… mas se vc ler… umas 45 vezes , vai perceber que eh um belo nome dado ao uso de “certos pradroes”…

Virou moda… agora não é mais “Regra de Negocio” e sim “Dominio da Aplicação”

Bah… quer trocar de nome troque… mas não ache que isso eh a ultima bolacha do pacote.

Concordo que há muito bafafá em cima de DDD, e em cima de qualquer outra coisa que ganhe um determinado status dentro da comunidade de desenvolvimento, como metodologias ágeis e, como você bem citou, DSLs. E alguns podem não concordar, mas o problema dessa visão é que parte-se do princípio que deve-se usar essas coisas para tudo o que você desenvolve hoje em dia. O próprio Eric Evans recomenda em seu livro que DDD deve ser usado para modelar domínios complexos. Da mesma forma DSLs devem ser usadas quando há realmente um ganho, pois ao menos em Java desenvolver uma DSL interna acaba sendo mais trabalhoso - embora o ganho em expressividade seja significativo e no geral valha a pena.

De certa forma tambem concordo, outra coisa que tem passado pela minha cabeça é que talvez a linguagem, no caso java e algumas outras não tenha subsidios para chegar em uma implementação interessante destas idéias “novas”. Aí quando alguem tenta fazer uma implementação fica aquela coisa estranha, meio deslocada, com cara feia mesmo. Java, entre outras é mais uma linguagem que implementa a filosofia da OO da melhor forma possível mas que ainda não domina toda a idéia pelo menos na sua melhor forma. Logo querer ir além disso talvez tenhamos que esperar mais um pouco.

ahahahah ainda não havia ouvido essa, gostei.

flws

Aproveitando…

public class DAOFactory {
	
	public static FaculdadeDAO getFaculdadeDAO(){
		return new FaculdadeDAOHibernate();
	}
}

seria melhor usar assim:

public class DAOFactory {
	
	public static FaculdadeDAO getFaculdadeDAO(){
		return FaculdadeDAOHibernate.getInstance();
	}
}

onde FaculdadeDAOHibernate usaria “Singleton” ?

tonyam,

Entendi que o autor se refere ao tempo em que estes patterns foram publicados e conhecidos pela comunidade.

flws

atualmente o pessoal usa DAO só pra encapsular o seu framework preferido de persistencia. Me lembro do pesadelo que era os tempos pré ORM e nos DAOs tinham milhares de concats encadeados… ali sim precisava isolar o acesso ao banco de dados.
hj em dia está tão simples que isso se resume colocar DAO no final do nome da classe e injetar a conexão com o banco. pra mim, dada a motivação atual, o que resta do padrão hj em dia é a burocracia.

Nossa senhora… outra discussao sobre esse assunto, mesmo tendo 324234 delas no forum de arquitetura, inclusive umas muito recentes…

É ruim ouvir comentários dizendo que DDD e DSL é blá blá blá. Oras, é lógico que você vai encontrar poucos casos reais de uso destas tecnologias, afinal, aqui, as pessoas ainda mal desapegaram do Struts. IMHO, dizer que DDD ou DSL não possui aplicações reais é completa ignorância.

Bem, continuo achando q DDD é um nome comercial pra OO.
Pow, para chegar num modelo OO bom, é necessário que se tenha analistas descobrindo quais são as responsabilidades. Uma coisa leva a outra.

foxpv:

Discordo. Pra mim são coisas complementares. Enquanto OO é sobre atribuir responsabilidades aos objetos, DDD é mais sobre interação com analistas de negócio para descobrir quais são essas responsabilidades.

Bem, continuo achando q DDD é um nome comercial pra OO.
Pow, para chegar num modelo OO bom, é necessário que se tenha analistas descobrindo quais são as responsabilidades. Uma coisa leva a outra.

uma coisa levar a outra não faz dessa coisa IGUAL a outra. Não entendo a motivação em querer igualar os dois. Será preguiça de ter que assimilar um conceito diferente?

Ainda que no livro de DDD sejam descritos vários design patterns para business objects, dizer que DDD == OO é ignorar o restante do conteúdo que é tão, ou até mais importante, e não está diretamente relacionado com a tecnologia de objetos.

Foram que esta atitude de igualar os dois tb pode levar iniciantes a estudarem DDD achando que irão aprender OO por tabela (ja que seriam iguais!). Mas esta é a receita para o desastre, IMO.

mochuara:

Ainda que no livro de DDD sejam descritos vários design patterns para business objects, dizer que DDD == OO é ignorar o restante do conteúdo que é tão, ou até mais importante, e não está diretamente relacionado com a tecnologia de objetos.

Foram que esta atitude de igualar os dois tb pode levar iniciantes a estudarem DDD achando que irão aprender OO por tabela (ja que seriam iguais!). Mas esta é a receita para o desastre, IMO.

hehe… semelhante aos textos do shoes…

ehhehe sera que é fake do shoes?

chun:

Eu sinceramente acho esse negocio de DDD um bafafá danado… eh que nem a tal da DSL , rapaz… eu realmente gostaria de ver um sistema que REALMENTE usa-se uma DSL… prq nego fala , fala ,fala e na hora de implementar… cade ? faz um enjambre e chamda de exemplo…

DDD é outro… milhoes de artigos… mas se vc ler… umas 45 vezes , vai perceber que eh um belo nome dado ao uso de “certos pradroes”…

Virou moda… agora não é mais “Regra de Negocio” e sim “Dominio da Aplicação”

Bah… quer trocar de nome troque… mas não ache que isso eh a ultima bolacha do pacote.

Concordo, e não é só com DDD. Na minha opinião existe toda uma atmosfera cult, e às vezes isso dá no saco, principalmente quando esses caras vêm falar bonito e atrapalhar o seu trabalho. Me lembro por exemplo quando eu usava abstract method e IoC há anos atrás no Delphi, sem saber sequer o nome daquilo. Porém eu não fiz nenhuma mágica, nem li nenhum livro do Martin Fowler, apenas fui lá e fiz. Mas na comunidade Java tudo tem que ter nome, status e pessoas a cultuar, pra criar um clima cult que ajude a verder livros, palestras, cursos, consultorias e sei lá o quê.

Outro exemplo foi quando li sobre BDD, achei uma certa encheção de linguiça. O pior pra mim nem é o autor em si demonstrar ou vender suas idéias (às vezes até acredito que não há fins promocionais em muitas delas), o pior é que aquilo acaba virando uma doutrina onde se fala demais e se vê muito pouco, onde as pessoas acreditam mais do que pensam.

Entenda bem, não estou dizendo que o livro de DDD por exemplo é puro blá blá blá, estou dizendo que, na minha opinião, às vezes se cria uma certa babação em torno dos assuntos, e o resultado final muitas vezes é aquele monte de código fedido posando de chique, que você tem que manter, ou aquele dinheiro que você perde em cursos bonitos na forma mas pobres no conteúdo, ou ainda aquele framework revolucionário que custa uma nota e você comprou depois de assistir aquelas palestras cheias das siglas da vez, e que te prometem a “alta produtividade em JEE” de sempre.

Resumindo, na minha opinião tem muita é frescura por aí.

"

renatosilva:

Concordo, e não é só com DDD. Na minha opinião existe toda uma atmosfera cult, e às vezes isso dá no saco, principalmente quando esses caras vêm falar bonito e atrapalhar o seu trabalho. Me lembro por exemplo quando eu usava abstract method e IoC há anos atrás no Delphi, sem saber sequer o nome daquilo. Porém eu não fiz nenhuma mágica, nem li nenhum livro do Martin Fowler, apenas fui lá e fiz. Mas na comunidade Java tudo tem que ter nome, status e pessoas a cultuar, pra criar um clima cult que ajude a verder livros, palestras, cursos, consultorias e sei lá o quê.

Outro exemplo foi quando li sobre BDD, achei uma certa encheção de linguiça. O pior pra mim nem é o autor em si demonstrar ou vender suas idéias (às vezes até acredito que não há fins promocionais em muitas delas), o pior é que aquilo acaba virando uma doutrina onde se fala demais e se vê muito pouco, onde as pessoas acreditam mais do que pensam.

Entenda bem, não estou dizendo que o livro de DDD por exemplo é puro blá blá blá, estou dizendo que, na minha opinião, às vezes se cria uma certa babação em torno dos assuntos, e o resultado final muitas vezes é aquele monte de código fedido posando de chique, que você tem que manter, ou aquele dinheiro que você perde em cursos bonitos na forma mas pobres no conteúdo, ou ainda aquele framework revolucionário que custa uma nota e você comprou depois de assistir aquelas palestras cheias das siglas da vez, e que te prometem a “alta produtividade em JEE” de sempre.

Resumindo, na minha opinião tem muita é frescura por aí.

Não me estranha, as pessoas são fortemente moldadas pela linguagem que utilizam pra programar. Por ser uma linguagem que exige escrever muito pra fazer pouca coisa quem programa em Java acaba acostumado a pensar que volume é indispensável para o sucesso. No caso da linguagem isto é verdade na maioria das vezes mesmo mas isto obviamente reflete em tudo que se relaciona a linguagem, como a criação de frameworks que querem resolver tudo e é prato cheio pra quem gosta de falar ao inves de escrever código.

A ideia do BDD é um ótimo exemplo, o que era pra ser apenas uma pequena correçnao de rumo na atitude de pensar os testes unitários se tornou em problema com direito a soluções na forma de framework.

renatosilva:

Concordo, e não é só com DDD. Na minha opinião existe toda uma atmosfera cult, e às vezes isso dá no saco, principalmente quando esses caras vêm falar bonito e atrapalhar o seu trabalho. Me lembro por exemplo quando eu usava abstract method e IoC há anos atrás no Delphi, sem saber sequer o nome daquilo. Porém eu não fiz nenhuma mágica, nem li nenhum livro do Martin Fowler, apenas fui lá e fiz. Mas na comunidade Java tudo tem que ter nome, status e pessoas a cultuar, pra criar um clima cult que ajude a verder livros, palestras, cursos, consultorias e sei lá o quê.

Outro exemplo foi quando li sobre BDD, achei uma certa encheção de linguiça. O pior pra mim nem é o autor em si demonstrar ou vender suas idéias (às vezes até acredito que não há fins promocionais em muitas delas), o pior é que aquilo acaba virando uma doutrina onde se fala demais e se vê muito pouco, onde as pessoas acreditam mais do que pensam.

Entenda bem, não estou dizendo que o livro de DDD por exemplo é puro blá blá blá, estou dizendo que, na minha opinião, às vezes se cria uma certa babação em torno dos assuntos, e o resultado final muitas vezes é aquele monte de código fedido posando de chique, que você tem que manter, ou aquele dinheiro que você perde em cursos bonitos na forma mas pobres no conteúdo, ou ainda aquele framework revolucionário que custa uma nota e você comprou depois de assistir aquelas palestras cheias das siglas da vez, e que te prometem a “alta produtividade em JEE” de sempre.

Resumindo, na minha opinião tem muita é frescura por aí.

Tenho um medo desse tipo de afirmacao simplificada assim. Nem tanto por quem escreve, mas mais por quem lê.

O que eu me pergunto, nao necessariamente sobre o colega que postou o trecho acima, mas por quem le e concorda de bate-pronto, é o quanto realmente o que é dito é babação e em determinada realidade realmente pode atrapalhar e o quanto isso é aquele velho e conhecido: “Nao entendi nada dessa papagaiada toda aí, vou continuar fazendo minhas gambiarras sem nome aqui que assim sou mais produtivo.” E acaba armando um parafernalha que so ele entende e por entender acha que é simples.

Sinceramente, nao consigo imaginar de que forma DDD possa atrapalhar em alguma coisa o desenvolvimento de um software, a nao ser no mais simples caso.

O que atrapalha e muito sao dois “analistas” discutindo qual a melhor implementacao (seja baseada em DDD ou nao) sem testar nenhuma. Aí ficam dias naquele blabla sem nexo e quando o projeto atrasa a culpa é do Java, do DDD, do Struts, Hibernate etc…

Pra criticar a pratica em si e preciso ter algum conhecimento sobre diferentes perspectivas, linguagens. Mas no caso do Java o que não falta são “entendedores”, inclusive dos reais problemas.