DAOs, Repository, Service, Entity e Aggregate ! Como unir ou jogar fora tudo isso ?

This message was edited 1 time. Last update was at 09/10/2007 13:01:29

Ola
Tempos atrás eu tive algumas discussões aqui no fórum e isso me esclareceu algumas duvidas. Porem após dois meses ainda me falta compreender alguns assuntos.
Eu andei lendo alguns comentários aqui no fórum, e fiquei com algumas duvidas se estou aplicando corretamente DAOs, Repository, Service, Entity e Aggregate.

Eu tenho as seguintes situações, uma fabrica de Repositório que coleta o DAO correspondente através de IoC, segue código abaixo:

Eu não quero transpor a injeção de dependência para o Cliente, então faço uso de uma fabrica para abstrair isso, como demonstrei no código acima.
Portanto o Service do Usuário pode verificar se um determinado login existe no banco de dados da seguinte forma:

Feito isso eu tenho tudo preparado para o Cliente verificar se o login existe, da seguinte maneira:

Conclusão:
1)A injeção de dependência foi adicionado para que eu não precise ficar controlando as transações, como vc pode perceber eu não precisei ficar escrevendo begin transaction, rollback e etc.

2)A Fabrica serve para esconder do cliente a injeção de dependência.

3)O Service não fez muito sentido, pois o contexto aqui é muito pequeno, mas imagine uma situação de cadastro de usuário, nessa situação o Service poderia fazer uso de outros Repository, e novamente eu não quero transpor essa lógica para o cliente, portanto digamos que o Service contém parte da lógica.

4)A Entity esta espalhada por todos os cantos, uso esta dentro do Service para passar o critério de busca, uso ela também no Cliente para popular os dados que são coletados da interface web.

5)Creio que esteja faltando o Aggregate, dessa forma não teríamos a Entity trafegando entre as camadas, mas eu particularmente acho muito trabalhoso ficar criando esses Aggregate e estes não me traz muitos benefícios.

6)Eu estou pensando em juntar o Entity com o Service, mas usando IoC para isso, assim o nosso Cliente poderia usar algo semelhante ao ActiveRecord dentro da Entity

7)Apesar de adicionar essas implementações eu ainda acho que estou caindo no problema do Modelo Anemico, e que ainda preciso me aprofundar mais nos conceitos de DDD. O DDD me ajudou mais na forma de conceber o projeto do que no código em sí. Aprendemos a não usar Waterfall, criamos uma linguagem comum de comunicação com os clientes, procuramos definir quem são os Peritos do Domínio e etc, porem acho que no código em si eu não evolui muito e percebi que os problemas de software estavam mais relacionados na concepção do projeto do que código fonte do projeto.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3417 Offline

Quem são as suas entidades ? Usuário, Login ou ambas ?
O que Login é de Usuário ?

Não existe [LogicadeAcessoADados]Repository e sim [Entidade]Repository
Seu sistema deve ter UsuarioRepository, ClienteRepository, PedidoReposity e não HibernateRepository.
(A menos, é claro, que Hibernate seja o nome de uma entidade ... )
Por outro lado não deve ter [Entidade]DAO e sim [LogicadeAcessoADados]DAO. Ou seja, deve ter HibernateDAO
e XMLDAO. ou DistribuidoComCacheDAO, ou JDBCDAO.

DAO são plugáveis, logo têm Factories e são injetados em outros objetos.
Repositorios não são plugáveis e não são obtidos de factories. Eles contém factories e as usam para
realizar seu trabalho, mas seu trabalho é único , ele é vinculado ao sistema , à logica de negocio.
Se a logica de negocio muda , a logica do repositorio muda , assim como a das entidades.
VC não irá nunca mais usar a logica anterior (*)

Reflita nestas questões para entender o que está errado no seu modelo DDD.

* Num desenvolvimento sadio e competente é claro. Se foi tomada uma decisão na empresa para impor a regra de negocio X espera-se que não se arrependam. Se isso for um problema podemos ainda criar estratégias de negocio dentro dos repositorios, mas isso é overkill para um ambiente normal de desenvolvimento. Por outro lados existem os CVS da vida para recuparar o código antigo se for realmente necessário.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

Ronildo,

a resposta para sua pergunta é bastante complexa para ser dada em um fórum, mas (acredite!!!) existe um jeito simples de usar MDD com Hibernate.

Abraço.

sergiotaborda wrote:Quem são as suas entidades ? Usuário, Login ou ambas ?
O que Login é de Usuário ?
Reflita nestas questões para entender o que está errado no seu modelo DDD.

Tudo bem, vou tentar me expressar melhor.
Uma entidade é uma abstraçao do mundo real, que quarda informaçoes de um determinado elemento. O conjunto de entidades pode representar uma tabela no banco de dados.

Para manipular essas entidades nos precisamos criar serviços responsáveis para esta tarefa. Saindo um pouco da informática vou tentar expressar essas idéias em algo mais simples que eu vejo no meu café de manhã.

Imagino o pão frances como uma entidade, o qual possui informações sobre as caracteristicas do mesmo. Para obter 10 pães eu faço uma requisição ao atendente da padaria, este por sua vez procura os pães dentro de uma cesta de pães e me retorna o pedido.

Creio que o exemplo acima seja um dominio, e vou tentar abstrair este problema do mundo real para uma possivel solução dentro da informatica, portanto segue solução abaixo.

O pão é uma entidade, eu sou o cliente ou servlet, o atendente é o serviço, e a cesta de pães é o repositorio. Eu poderia especificar varios repositorios diferentes, pois uma padaria faz diversos tipos de pães, assim o atendente (Servico) pode retornar diferentes tipos de pães, pois ele tem a sua disposição diferentes repositórios.

Se isto estiver correto com as regras do DDD, eu nao vejo muita diferença sobre o modelo anemico. O modelo anemico citado por Martin Fowler diz que as entidades nao podem ser separadas da logica, portanto como fazer isso no exemplo da padaria ?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3417 Offline

Ronildo, a pergunta não era retórica. Quais são as suas entidades ?

sergiotaborda wrote:Ronildo, a pergunta não era retórica. Quais são as suas entidades ?

Login é a minha entidade

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3417 Offline

ronildobraga wrote:

sergiotaborda wrote:Ronildo, a pergunta não era retórica. Quais são as suas entidades ?

Login é a minha entidade

Se Login é a sua entidade qual é a Identidade dele ?

E Usuário , não é uma entidade ? Não existe no seu sistema. Se existe, qual é a relação dele com Login?

This message was edited 1 time. Last update was at 31/05/2008 11:41:13

Estou ressucitando este tópico, porque tive um problema semelhante, e resolvi da seguinte forma:

Ou seja, login seria um service, e não uma entidade.
Estaria correto isso? Ou a classe Usuario deve ficar responsável pelo controle de acesso?
Abraços

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Olá,

A maneira que você fez me parece uma boa.
O objeto usuário não deve saber se autenticar pois autenticação é tarefa de infra, então neste caso o service é uma boa solução.

Se você quiser explicitar no seu modelo de dominio que o usúario loga, então você poderia ter o método logar() na entidade usuario, e esse método delegaria a tarefa para o service (ainda assim o servico continua fazendo o controle de acesso).

[]s
Ferry

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Não gostei muito do HibernateRepository porque dá a impressão que o conceito de repository não foi compreendido.
O repository não deve existir se ele não existir na situação de negócio.

Pra falar a verdade acho que você tentou usar o DDD como um template de arquitetura e isso não dá muito certo, pois DDD é um processo que tem requisitos de aderência e deve ser aplicado em concordância com a equipe e com presença dos domain experts.

[editado: propaganda nao, obrigado]

Grande Abraço,

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Esqueci de quotar, meu comentário foi em relação ao post do tnaires.

[]s

Notícias, artigos e o maior fórum brasileiro sobre Java