Pessoal, esotu com uma dúvida em relação a quando vou deletar uma Entidade Grupo do meu sistema.
Antes de excluí-la preciso certificar que não existem Usuários relacionados a ela.
Esta regra deve ficar em qual parte do meu DDD?
Em um Service ou na própria Entity?
Obrigado
no banco de dados 
- que seria tratado (tal excecao) na parte onde vc chama o serviço de excluir
Mas tipo, vc axa certo verificar se o Grupo está relacionados a Usuários no banco?
Eu pensei q o melhor seria no Service…
Aguardo opiniões da galera ae
Obrigado
onde está a normalizacao das suas regras de dados ?
Mas isso nao é uma regra de negócio?
é uma regra de negocio que deve estar normalizada dentro do banco de dados.
Tem que tá normalizada no banco, mas eu não usuaria exception do banco pra tratar esse erro. Na verdade eu tento não dar exception de banco nunca.
Eu colocaria a regra na aplicação pra verificar se pode ou não deletar antes de mandar isso pro banco. Normalmente eu faço um método na entity que verifica se a entity é “deletavel” e no service eu faço a verificação antes de mandar deletar.
[]'s
Rodrigo Auler
Se isso é regra de negócio deve permanecer no domain model. Usar uma exception do banco de dados vai amarrar seu domain a uma implementação específica de infraestrutura. Acho que a sugestão do post acima do meu é mais válida. Coloque essa validação no metodo de deleção da entity e imaginando que haja um repository para essa entity ou para seu Agregate, o melhor é que essa logica fique no repositorio.
Grande Abraço,
[quote=feliperod]o melhor é que essa logica fique no repositorio.Grande Abraço,[/quote] não concordo. isto nao seria o objetivo do DAO. voce deve possuir uma camada intermediaria que contemple quais as validacoes e transacoes associadas das suas classes de modelo de dominio. agora quanto a abstratir este comportamento, voce deve se beneficiar de algum recurso AOP, interceptors, proxy, intercepting filter ou dependendo do framework que voce usar para tratar comportamentos excepcionais como de integridade/referencial.
Fael, se for só questão de transação ou qualquer outra questão de infraestrutura tudo bem ficar no DAO, porém se a validação expressa uma regra de negócio, ou melhor, é necessária para atender a uma regra de negócio deve ficar no domain, caso contrário você deixará de fora do seu domain um conceito de negócio que pode fazer falta depois.
Por isso que postei:
Grande Abraço,
Mas se é regra de negócio não deveria ficar na implementacao do repositorio, que é infraestrutura.
[quote=cmoscoso]
Mas se é regra de negócio não deveria ficar na implementacao do repositorio, que é infraestrutura.[/quote]
A implementação do Repository só deve ser infraestrutura se não houver regra de negócio. Caso contrário o repositório deve ter uma implementação no domain model e essa implementação faz uso de uma classe de infraestrutura. Essa impressão que vc teve é normal da confusão de que um repository é um DAO e vice-versa.
Tenha sempre em mente que qualquer regra de negócio DEVE (obrigatóriamente) estar presente no Domain Model para que você possa dizer que está usando DDD.
Grande Abraço,
repositório não é infraestrutura (para todo o sempre, amém)
[quote=feliperod]
A implementação do Repository só deve ser infraestrutura se não houver regra de negócio. Caso contrário o repositório deve ter uma implementação no domain model e essa implementação faz uso de uma classe de infraestrutura. Essa impressão que vc teve é normal da confusão de que um repository é um DAO e vice-versa.
Tenha sempre em mente que qualquer regra de negócio DEVE (obrigatóriamente) estar presente no Domain Model para que você possa dizer que está usando DDD.
Grande Abraço,[/quote]
Essa confusao entre dominio e regras de negocio que voce esta fazendo é comum mas deixa eu tentar explicar…
Você sugeriu que, sendo regra de negócio poderia estar no repositorio e eu discordei dizendo que apesar do repositorio ser um objeto do dominio ele não representa um conceito de negócio e por isso nao deveria conter a tal regra.
Ou seja, apesar do dominiio ser o local das regras de negocio nao significa que ela deva estar em qualquer lugar dentro dele. Existem objetos de dominio que tem papel de suporte e nao de negocio, é o caso de repositorios e factories.
[quote=cmoscoso]
Essa confusao entre dominio e regras de negocio que voce esta fazendo é comum mas deixa eu tentar explicar…
Você sugeriu que, sendo regra de negócio poderia estar no repositorio e eu discordei dizendo que apesar do repositorio ser um objeto do dominio ele não representa um conceito de negócio e por isso nao deveria conter a tal regra.
Ou seja, apesar do dominiio ser o local das regras de negocio nao significa que ela deva estar em qualquer lugar dentro dele. Existem objetos de dominio que tem papel de suporte e nao de negocio, é o caso de repositorios e factories.[/quote]
Eu to fazendo confusão entre domínio e regra de negócio? Você leu o livro do Eric Evans? Domain DEVE ser a mais pura expressão da lógica de negócio. Isso é domain. Domain é a regra de negócio expressada em código, linguagem e documentos. Como o Lezinho disse:
Se nào é infraestrutura é Domain. Se é Domain então é regra de negócio. O fato de você não encontrar regra de negócio para colocar no repositório permite que a implementação dele fique numa outra camada de sua aplicação, mas não esqueça que pelo aplicação do conceito “Intetion-Revealing Interfaces” uma interface, por mais simples que seja, DEVE representar conceito de negócio. Factories e Repositories cuidam do ciclo de vida dos objetos. Isso inclui garantir a integridade referencial na criação e na deleção e talvez você ache que isso é apenas suporte, mas não é. Isso faz parte do negócio. Permitir que uma venda só seja criada se o cliente citado existir é uma regra de negócio e não questão de suporte.
Sem querer ser chato ou prepotente, mas acho que todos nós devemos buscar melhor o significado da palavra domain antes de sair atirando por aí.
Hummm… será que este assunto é tão simples para se resumir assim? Basta simplesmente pesquisar? O assunto não é tão simples… dê uma pesquisada aqui no GUJ mesmo. Pelo menos lendo a thread abaixo fica mais simples entender o ponto de vista do cmoscoso, que aliás, eu entendi bem. 
http://www.guj.com.br/posts/list/85604.java
Obs: É bom ler toda a Thread, e porradas por aí sobre regra de negócio no repositório é o que não falta.
… embora a própria aplicabilidade do termo “regras de negócio” seja questionável e relativa.
Essa thread citada eu já conheço e até participei dela com alguns comentários.
Sei que o assunto nao é tão simples, mas entender o significado de “domain” no contexto de DDD é um ponto importante.
Acho que a principal confusão é a questão da implementação dos repositories. Como qualquer boa quebra de paradigma fica fácil de confundir o que sempre fizemos com o que fazer nesse novo caso. Daí surge a confusão entre DAO e Repository. Aí como essa confusão existe, também adotaram a idéia de que repository é dividido entre declaração, que ficaria na camada de Domain e implementação que ficaria na camada de infraestrutura. Essa pressuposição é errada porque não é uma regra geral. É apenas uma das possibilidades. Mas se sairmos um pouco dos “patterns” que o DDD apresenta e tentarmos usar esses “patterns” no contexto geral do DDD, buscando o resultado através do processo de realizar DDD conseguimos enxergar melhor um pouco. Pensemos em conceitos de negócio e no modelo não só como implementação mas também como declaração.
Um bom exemplo seria definir o que é o domain model fisicamente falando. É um documento? É o código? É a forma com que fazemos as coisas na arquitetura? São perguntas que só podem ser respondidas com muito estudo de conceitos e com o significado de Domain na ponta da língua.
Pelo dicionário Domain significa “uma esfera de conhecimento, atividade e influência de uma determinada situação”. Situação no caso é a situação de negócio a ser tratada. Acho que já é um bom começo pra responder o que é o domain model.
Grande Abraço,
Domain Model é sobre regra de negócio (mas não somente sobre elas já que temos limitações da linguagem, como o próprio Repositório que em muitos domínios não faz sentido) mas regra de negócio transcende o Domain Model. regra de negócio vai interferir, por exemplo, em como informações são apresentadas ou em como dois sistemas se comunicam. Quase tudo que está no Domain Model é regra de negócio mas nem toda regra de negócio está no Domain Model.
Cuidado com afirmações como ‘DEVE’, ‘certo’ e ‘errado’. Para a maioria das coisas não existe certo ou errado, existe apropriado ou não-apropriado e mesmo assim de acordo com um autor ou pensamento.
No mais, creio que o Grupo, ao ser apagado, deva apagar também seus usuários. Isso é uma regra de negócios pertencente à entidade grupo e não ao repositório. Cuidar do ciclo de vida de um objeto é alo diferente de executar suas responsabilidades.
a partir daí você não conseguirá obter reuso dentre diversas lógicas de negócio que são repositories. seria interessante uma interface de serviço obter seu repository associado. neste caso uma interface de serviço acessa outra(interface de serviço que possui seu repository associado) e não diretamente repositories de um conjunto de regra de negócios. tente representar esta sua idéia a partir de um diag. de sequência. e explique-se melhor aqui.
[editado=“melhoria de interpretacao”]
não li o livro de eric evans sobre DDD, mas vou me aprofundar nestes pontos, para saber das razões. transparece que ele dá abertura demais. até então este é o meu ponto de vista!