DDD: Regras de negócio nos repositórios?

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Ontem eu estava assistindo a um vídeo de uma palestra do Giovanni Bassi sobre DDD (http://unplugged.giggio.net/unplugged/post/Video-sobre-Domain-Driven-Design.aspx), em geral achei muito boa mas não consegui engolir uma coisa:
O Giovanni diz que repositórios não podem ter regras de negócio.

Mas o repositório não faz parte da camada de negócios? Nesse caso, por que não poderia ter regras de negócio?

Segundo o que tenho lido, a diferença entre um repositório e um DAO é justamente essa: O DAO é infra-estrutura, e por isso não pode ter regras de negócio. Já o repositório faz parte do negócio, por isso pode executar validações e tudo mais

Já começa errado dizer que seu domínio esta em uma camada. Esqueça esse negócio de camada. Pense em um domínio de negócio. E nem o repositório e nem ninguém possui a regra de negócio como era feito com os BO (business objects) as regras de negócios estão implícitas no domínio como um todo.

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Ok... Então quais classes devem validar estas regras?

magnomp wrote:Ok... Então quais classes devem validar estas regras?

Cite um exemplo de validação !!!!

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Vejamos....

Em um sistema de hoteis, não pode haver mais de uma conta para o mesmo quarto no mesmo período

Legal...agora qual é o nosso domínio ?

Quarto
Hotel
Despesa
Serviço
Periodo
Reserva
etc..

Um quarto possui várias reservas, cada reserva é composta por um período. Cada reserva só pode conter uma conta por período. Onde isso deveria ser feito ??? Se eu estivesse escrevendo este sistema seria na reserva do quarto, após a reserva ninguém mais pode entar neste quarto até o término do período, o que garante que este período só tera uma conta.

This message was edited 1 time. Last update was at 14/06/2010 14:04:28

Tem uma Thread que fala sobre isso e apesar de um pouco antiga tem bastante conteúdo pra te ajudar, creio eu.

http://www.guj.com.br/posts/list/85604.java

[]s

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

magnomp wrote:Vejamos....

Em um sistema de hoteis, não pode haver mais de uma conta para o mesmo quarto no mesmo período

Num modelo orientado a objetos invariantes sao implementadas advinha, nos objetos. Encapsulamento é seu amigo.

Virtual Machine Man Membro desde: 18/10/2006 17:04:08 Mensagens: 521 Offline

Pelo pouco que sei de DDD domain driver designer é que vc deixa o modelo anemico de lado e adota as regras de negocio na camada de modelo, onde possui suas entidades.

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Emerson Macedo,
Eu já havia lido essa thread, foi uma discussão realmente boa

Giulliano,
Isso implica que o quarto tenha que acessar o repositório, para poder consultar as reservas. Correto?
Não há nenhum problema nisso?

magnomp wrote:Emerson Macedo,
Eu já havia lido essa thread, foi uma discussão realmente boa

Giulliano,
Isso implica que o quarto tenha que acessar o repositório, para poder consultar as reservas. Correto?
Não há nenhum problema nisso?

Sim...se o quarto precisar acessar qualquer informação ele pode recorrer aos repositórios que por sua vez podem recorrer a um DAO se for necessário.

Mas olha só...no mundo real vc não cria um quarto e busca uma reserva para ele. Vocẽ cria uma reserva e associa ela a um quarto disponível.

; )

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Acho radicalismo dizer que repositórios não podem conter regras de negócio, uma vez que eles pertencem ao negócio. O que acontece é que muitos desenvolvedores adotam a implementação em Java onde repositório é uma interface implementada diretamente por um DAO, neste caso regras de negócio na camada de infraestrutura pode não ser uma boa. Mas o crédito disto é da implementação e não do padrão em si.

JavaEvangelist Membro desde: 30/04/2007 07:43:01 Mensagens: 424 Offline

Giulliano wrote:

magnomp wrote:Emerson Macedo,
Eu já havia lido essa thread, foi uma discussão realmente boa

Giulliano,
Isso implica que o quarto tenha que acessar o repositório, para poder consultar as reservas. Correto?
Não há nenhum problema nisso?

Sim...se o quarto precisar acessar qualquer informação ele pode recorrer aos repositórios que por sua vez podem recorrer a um DAO se for necessário.

; )

Ou seja, abusando da abstração, poderia enxergar o repositório como uma "facade" para um DAO ou outras implementações de consultas a arquivos, banco de dados, WS, etc..?

Aproveitando a discução:

imaginem um caso, onde é necessário buscar todos os quartos que estarão disponíveis para uso em um período futuro.
Com certeza esta busca teria um certo grau de complexidade que, inevitavelmente, iria colocar lógica de negocio no repositorio. Se o repositório não tiver acesso a nem isso da lógica de negócio, seria necessário trazer todos os quartos, todas as reservas e o que mais fosse necessário, fazer um processamento via linguagem de programação, o que geraria um overhead grande.

Neste caso, o que é recomendado?

Abraços

Daniel_MV wrote:
Ou seja, abusando da abstração, poderia enxergar o repositório como uma "facade" para um DAO ou outras implementações de consultas a arquivos, banco de dados, WS, etc..?

No livro de DDD do Eric Evans (o livro azul) ele diz para enxergarmos os reposiórios como Coleções com métodos epecializados para seu negócio, exemplos:

adicionar
retornarTodosOsQuartos()
retornarQuartosDisponiveis()

etc.

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