DDD - Criticas à minha arquitetura

Programação Arquitetura
#81

Certo. Só quero deixar claro que, quando eu falo que o ou repositório ou o DAO conhece sobre o negócio, quero dizer que um método de consulta específico do negócio é implementado no mesmo. Métodos como esses:

[code]
public interface EnqueteRepositorio {
// Retorna todas as enquetes criadas por um usuário do sistema.
List enquetesPorUsuario(Usuario u);
}

public HibernateEnqueteRepositorio implements EnqueteRepositorio {
public List enquetesPorUsuario(Usuario u) {
// Aqui eu utilizaria Session + Criteria
}
}[/code]

#82

Não precisa de um caso para entender a diferença. É como entender a diferença entre verbo e substantivo; não preciso lhe dar exemplo para explicar a diferença.

Talvez esteja pensando em implementação, que a de um e a de outro são iguais ou semelhantes. Tlv até sejam, mas a sua responsabilidade, o papel que têm no sistema, a frequencia de alteração, a reutilização, e mais importante que isso o principio de design por detrás de cada um é completamente diferente.

Não é porque vc chama DAO a uma classe que ela vira uma implementação de DAO. O mesmo para qq outro padrão.
Eu , particularmente, acho absurdo o exagero nos prefixo e sufixos ( tipo, ClienteVO). Arrisco a dizer que 90% dos objetos sufixados com DAO , hoje em dia, são na realidade implementações do padrão Repositorio. Especialmente se Hibernate ou JPA for usado.

O DAO com regras de negocio inclusas é algo do passado, que só faz sentido com vc trabalha com sistemas legados e codigo esparguete ( sem divisão de responsabilidade)

#83

Eu até já tive um caso onde o Repository não era uma Interface… mas era uma classe abstrata… que o DAO implementava… que uma fabrica retornava… no final, mesma coisa…

Antes nós faziamos…
Servlet -> Façade -> Service -> Factory -> DAO Interface -> DAO Impl -> DTO
Agora, seria algo parecido com…
Controller -> DomainFaçade -> [Service] -> Registry -> Repository -> DAO -> Entity <- TO | VO

Acho que isso é vicio antigo, não?!

#84

Saiu um ótimo artigo na InfoQ que fala sobre aspectos práticos do desenvolvimento com DDD:

#85

[quote=tnaires]
Certo. Só quero deixar claro que, quando eu falo que o ou repositório ou o DAO conhece sobre o negócio, quero dizer que um método de consulta específico do negócio é implementado no mesmo. Métodos como esses:

[code]
public interface EnqueteRepositorio {
// Retorna todas as enquetes criadas por um usuário do sistema.
List enquetesPorUsuario(Usuario u);
}

public HibernateEnqueteRepositorio implements EnqueteRepositorio {
public List enquetesPorUsuario(Usuario u) {
// Aqui eu utilizaria Session + Criteria
}
}[/code][/quote]

Postei exatamente sobre isso aqui:
http://www.guj.com.br/posts/preList/94314/507424.java#507424

#86

[quote=sergiotaborda]
Não precisa de um caso para entender a diferença. É como entender a diferença entre verbo e substantivo; não preciso lhe dar exemplo para explicar a diferença.

Talvez esteja pensando em implementação, que a de um e a de outro são iguais ou semelhantes. Tlv até sejam, mas a sua responsabilidade, o papel que têm no sistema, a frequencia de alteração, a reutilização, e mais importante que isso o principio de design por detrás de cada um é completamente diferente.

Não é porque vc chama DAO a uma classe que ela vira uma implementação de DAO. O mesmo para qq outro padrão.
Eu , particularmente, acho absurdo o exagero nos prefixo e sufixos ( tipo, ClienteVO). Arrisco a dizer que 90% dos objetos sufixados com DAO , hoje em dia, são na realidade implementações do padrão Repositorio. Especialmente se Hibernate ou JPA for usado.

O DAO com regras de negocio inclusas é algo do passado, que só faz sentido com vc trabalha com sistemas legados e codigo esparguete ( sem divisão de responsabilidade)[/quote]

Eu compreendi que DAO é um conceito de persistência e Repository é um conceito de negócio (uma Collection pode ser um repository).

Eu entendo que nomenclatura é algo muito importante.

Mas para mim, a nome DAO e Repository representam coisas com propósitos muito parecidos. Então se eu ver uma objeto do tipo ***DAO e ***Repository em uma classe da camada de negócio, eu sei exatamente para que serve para praticamente a mesma coisa na grande maioria dos casos.

Talvez se o Repository precisar fazer uma regra, validação, processamento, etc, antes de acessar o mecanismo de persistencia valeria ter um repository encapsulando um DAO.

Alguém pode colocar um exemplo de um projeto real? (Não vale projeto da NASA :twisted: )

#87

Qualquer projeto. Se sua classe de negócios precisa obtêr um objeto da persistência pra quem ele pede?

#88

Vc está no bom caminho, mas se ainda acha que o cocneito de DAO e Repositorio são muito semelhantes precisa ir mais além. Tem que chegar no ponto onde entende que eles são completamente diferentes.

Isso vai ser uma dificultada já que a maioria dos projetos opta por implementar classes com papel de repositorio chamadas DAO e usando hibernate. Ou seja, confusão total.

#89

java.sql.Connection :stuck_out_tongue:

Brincadeira. :stuck_out_tongue:

Geralmente para o DAO.

Ainda não entendi a confusão.

public interface AlgumaEntidadeRepository {
    public void save(AlgumaEntidade a);
    public void delete(AlgumaEntidade a);
    public void find(AlgumaEntidade a);
    public void List&lt;AlgumaEntidade&gt; findAll();
    public void List&lt;AlgumaEntidade&gt; findAllAlgumaEntidadeByAlgumAtributo(XYZ xyz);
}

e o meu DAO implementando a interface.

Qual a grande sacada aqui?

#90

[quote=Rubem Azenha]

Ainda não entendi a confusão.

public interface AlgumaEntidadeRepository {
    public void save(AlgumaEntidade a);
    public void delete(AlgumaEntidade a);
    public void find(AlgumaEntidade a);
    public void List&lt;AlgumaEntidade&gt; findAll();
    public void List&lt;AlgumaEntidade&gt; findAllAlgumaEntidadeByAlgumAtributo(XYZ xyz);
}

e o meu DAO implementando a interface.

Qual a grande sacada aqui?[/quote]

A sua interface é de um Repositório (que não faz sentido ser uma interface para começo de conversa, mas deixa para lá). A sua interface depende do dominio. Blz.
Agora, o DAO é um objeto que não depende do dominio. Essa é a sacada.

Mais detalhes aqui
Leia com atenção o topico e todas as referencias citadas nele.

#91

Calma, baby steps. Agora leia isso aqui.

#92