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

Assuntos Gerais Agile
#21

[quote=marvinla]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[/quote]

Nao tem nada de complexo, mas o que vc chama de regra de negocio na verdade é apenas um criterio de busca. O exemplo é ruim pra explicar DDD porque vc esta criando repositorios pensando em requisitos do ponto de vista do usuario. Mas ninguem precisa criar domain model pra fazer uma visualizacao do banco de dados. DDD nao é uma nova maneira de fazer relatorios ou CRUD.

Mas o que fazer se o domain model precisa confirmar uma reserva e pra isso precisa checar se os quartos estaos disponiveis? Bom, parece mais facil agora ne?

#22

[quote=mochuara][quote=marvinla]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[/quote]

Nao tem nada de complexo, mas o que vc chama de regra de negocio na verdade é apenas um criterio de busca. O exemplo é ruim pra explicar DDD porque vc esta criando repositorios pensando em requisitos do ponto de vista do usuario. Mas ninguem precisa criar domain model pra fazer uma visualizacao do banco de dados. DDD nao é uma nova maneira de fazer relatorios ou CRUD.

Mas o que fazer se o domain model precisa confirmar uma reserva e pra isso precisa checar se os quartos estaos disponiveis? Bom, parece mais facil agora ne?[/quote]

Pra mim este é o ponto mais critico de entender: no caso eu teria um metodo acessível pelo menu domain model: quartosDisponiveis(DataInicial, DataFinal). Este método acessaria a fonte de dados atravéz do DAO, WS, o que for para trazer as reservas do período e verificaria quais quartos não estão na lista, estes serão os disponíveis.
Ou, poderia ser feito atravez de uma única instrução SQL, ou mesmo HQL ou Criteria do Hibernate, porém a lógica de verificar quais quartos estão disponíveis estaria sendo codificada na camada de infra.
Isso afetaria a performance, visto que, se fizesse do primeiro modo, teria que, realizar 1 acesso à fonte de dados para buscar TODOS os quartos, 1 acesso para buscar TODAS as reservas do período, e ainda verificar quarto a quarto qual está disponível.
Neste exemplo pode ser banal, mas em um ambiente com um grande volume de dados, isso pode fazer a diferença.

#23

Acho que o grande problema aqui é que as pessoas acham que isto

é uma regra de negocio.

Depois dizem que se eu preciso fazer uma pesquisa irada para trazer os quartos que podem ser reservados no periodo em que o sol é ocultado por marte então eu tenho que escrever isso numa super hiper marte SQL matador que executa em 1 segundo… não.

Regras de negocio são coisas como “duas pessoas não podem reservar o mesmo quarto simultaneamente”, como eu forço isto ? Com queris ? Não. Com validadores. AS queries são ferramentas para perguntar, mas não para decidir. Vc cria um validador que consulta o banco e pergunta “tem alguem reservando o quarto neste peridodo” ? e a query vai responder, sim/ não . E o validador vai bloquear o ato de reserva ou não.

As queries matadoras são necessárias para agilizar a resposta À pergunta. Saber fazer a pergunta do jeito certo é muito importante, mas é uma questão de performance, não é uma questão de chegarou não na resposta. Em sistemas antigos pre-SQL isso nem sequer existe. vc faz um while e testa todos os registro na mão.

Portanto, repositorios podem ter regras de negocio ? Não. Repositorios existem para encontrar coisas, fazer (boas) perguntas. Não para decidir, impedir, proibir, controlar…
Agora, significa isso que repositorios ignoram o negocio ? Não. Eles sabem exactamente de que tipo de assunto estamos falando e o valor da pergunta que fazem.
Essa é diferença do DAO… O Dao não tem regras e ignora o negocio. Ele é um serviço de dados (dados, não entidades. Não se chama Entity Access Objet)

E claro que repositorios não são DAO nem façades para daos, nem interfaces de daos, nem coisas nenhuma dessas. Repositório é uma coisa e DAO é outra.
(Eu gostaria de saber quem foi o cretino que espalhou esse conceito de DAO e repositorio é a mesma coisa… ).

P.S. Eu sei quem foi o dito cujo. É uma pergunta retórica.

#24

[quote=sergiotaborda]…
[/quote]

Olá sergiotaborda, obrigado pela resposta. Ajudou ainda mais a clarear um dos pontos mais críticos pra mim.

#25

Hahahahahahahahahahahah!

flws

#26

[quote]Regras de negocio são coisas como “duas pessoas não podem reservar o mesmo quarto simultaneamente”, como eu forço isto ? Com queris ? Não. Com validadores.
(…)
Portanto, repositorios podem ter regras de negocio ? Não. Repositorios existem para encontrar coisas, fazer (boas) perguntas. Não para decidir, impedir, proibir, controlar…
Agora, significa isso que repositorios ignoram o negocio ? Não. Eles sabem exactamente de que tipo de assunto estamos falando e o valor da pergunta que fazem. [/quote]

Então não existem validações diretamente nos repositórios. Ao invés disso, os repositórios passam a bola para outra classe para fazer as validações antes de salvar as informações. É isso?

#27

[quote=magnomp][quote]Regras de negocio são coisas como “duas pessoas não podem reservar o mesmo quarto simultaneamente”, como eu forço isto ? Com queris ? Não. Com validadores.
(…)
Portanto, repositorios podem ter regras de negocio ? Não. Repositorios existem para encontrar coisas, fazer (boas) perguntas. Não para decidir, impedir, proibir, controlar…
Agora, significa isso que repositorios ignoram o negocio ? Não. Eles sabem exactamente de que tipo de assunto estamos falando e o valor da pergunta que fazem. [/quote]

Então não existem validações diretamente nos repositórios. Ao invés disso, os repositórios passam a bola para outra classe para fazer as validações antes de salvar as informações. É isso?[/quote]

não. Os repositorios não fazem validações. Quem faz validações são os serviços. ( na realidade quem faz são validadores, e os serviços usam esses validadores) São eles que modificam as coisas, logo eles que precisam se certificar que podem mudar. As validações são controladas nos serviços. Os repositorios servem para ler dados ( aka fazer pesquisas, aka executar queries)

Se houver um dado inválido o serviço aborta e o repositorio nem é chamado.

As actions tb podem fazer validações desde que invocando um validador.

#28

Nesse caso, o que é que os repositórios acrescentam ao sistema para justificar o seu uso? Por que não usar DAOs apenas?

#29

Voce pode usar DAO apenas, mas faca ele se passar por um repositorio para os objetos de dominio.

#30

[quote=marvinla][quote=mochuara][quote=marvinla]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[/quote]

Nao tem nada de complexo, mas o que vc chama de regra de negocio na verdade é apenas um criterio de busca. O exemplo é ruim pra explicar DDD porque vc esta criando repositorios pensando em requisitos do ponto de vista do usuario. Mas ninguem precisa criar domain model pra fazer uma visualizacao do banco de dados. DDD nao é uma nova maneira de fazer relatorios ou CRUD.

Mas o que fazer se o domain model precisa confirmar uma reserva e pra isso precisa checar se os quartos estaos disponiveis? Bom, parece mais facil agora ne?[/quote]

Pra mim este é o ponto mais critico de entender: no caso eu teria um metodo acessível pelo menu domain model: quartosDisponiveis(DataInicial, DataFinal). Este método acessaria a fonte de dados atravéz do DAO, WS, o que for para trazer as reservas do período e verificaria quais quartos não estão na lista, estes serão os disponíveis.
Ou, poderia ser feito atravez de uma única instrução SQL, ou mesmo HQL ou Criteria do Hibernate, porém a lógica de verificar quais quartos estão disponíveis estaria sendo codificada na camada de infra.
Isso afetaria a performance, visto que, se fizesse do primeiro modo, teria que, realizar 1 acesso à fonte de dados para buscar TODOS os quartos, 1 acesso para buscar TODAS as reservas do período, e ainda verificar quarto a quarto qual está disponível.
Neste exemplo pode ser banal, mas em um ambiente com um grande volume de dados, isso pode fazer a diferença.[/quote]

Não é um problema de persistencia, mas de design. Se trata de um sistema real vc deve primeiro saber distinguir regras de negocio de estado essencial, estado acidental, logica e validacoes existentes. E sim, saber o que esta fazendo faz toda a diferenca!

#31

Voce pode usar DAO apenas, mas faca ele se passar por um repositorio para os objetos de dominio.
Tá, mas na prática, o que diferencia um repositório de um DAO, além do fato de um ficar na camada de domínio e o outro ser infraestrutura?

O que pode ser feito em um repositório que não pode ser feito em um DAO?

#32

[quote=magnomp]Voce pode usar DAO apenas, mas faca ele se passar por um repositorio para os objetos de dominio.
Tá, mas na prática, o que diferencia um repositório de um DAO, além do fato de um ficar na camada de domínio e o outro ser infraestrutura?

O que pode ser feito em um repositório que não pode ser feito em um DAO?[/quote]

Nao estou a par da ultima definicao de DAO, mas repositorios nao precisam fazer nada, sao apenas contratos estabelecidos entre o domain model e o outro lado.

#33

Fala pessoal, tópico antigo mas queria apenas expressar qual a minha interpretação da diferença entre DAO e Repository e também passar uma ideia para validação de regra de negócio.

Bem como já foi dito a DAO faz parte da infra e repository do domínio, sendo assim a DAO não conhece o Domain, neste caso o repository fica com a responsabilidade de manipular suas Entity, ou seja, os dados vem da DAO (infra) e o repository (Domain) “transcreve” os dados para a Entity.

Falando em regra de negócio, o repository não deve decidir, ele apenas executa a sua função que é manipular as Entity. Validação de regras deve ficar no Serviço, cada serviço deve conter suas regras para manter o domínio coeso.

Uma boa forma de centralizar essas regras são as Specifications. Com esse pattern vocé poderar ter mais liberdade para adicionar ou retirar regras com maior flexibilidade, injetando as Specifications necessárias para cada serviço.

Bem galera, esse são os meus 2 cents na discussão… rs
Abraço!

#34

E o JPA, como ficaria nesse caso? As entitys aidan conteriam as anotações, e seriam vistas pelo DAO?

#35