Carlos, o repositório tem conhecimento de negócio a partir do momemto que ele representa a regra de se “conhecer um rendimento aprovado”, ter um rendimento em estado de aprovado é uma coisa do negócio, que é representado nas regras do negócio do mundo real e foi transposto para um método de consulta do repositório.
[quote=Maurício Linhares]
Carlos, o repositório tem conhecimento de negócio a partir do momemto que ele representa a regra de se “conhecer um rendimento aprovado”, ter um rendimento em estado de aprovado é uma coisa do negócio, que é representado nas regras do negócio do mundo real e foi transposto para um método de consulta do repositório.[/quote]
Se o que você chama de regra de negocio é construir uma query que procura na coluna STATUS da tabela RENDIMENTOS pelo valor “APROVADO”, esta perfeito!
Mas isso na real nao é regra de negocio mas sim infraestrutura de persistencia e bancos de dados nao armazenam regras de negocio.
E como é que você sabe que é apenas isso? Será que é sempre assim? Eles nunca tem conhecimentos de nada do negócio?
Num dos últimos sistemas que eu trabalhei, o site fazia recomendações de produtos aos usuários com base no que o usuário tinha visto ou navegado, se isso não é regra de negócio também eu não sei mais o que é.
Moscoso, eles não vêm do domínio, no sentido que não existem no mundo real geralmente não existem repositórios, mas eles são parte do domain model.
E como é que você sabe que é apenas isso? Será que é sempre assim? Eles nunca tem conhecimentos de nada do negócio?
Num dos últimos sistemas que eu trabalhei, o site fazia recomendações de produtos aos usuários com base no que o usuário tinha visto ou navegado, se isso não é regra de negócio também eu não sei mais o que é.[/quote]
A regra de negocio esta em como são colhidas as informacoes do usuario, baseado na sua interacao com o site, e na forma de recomendar os produtos de acordo com as informacoes obtidas. O papel do repositorio é secundario.
Na maioria das vezes objetos de negocio recorrem a repositorios para consultas simples. Outras vezes pode ser util infiltrar objetos de negocio no repositorio atraves de parametros da sua interface. Assim a regra de negocio continua encapsulada e deixa o repositorio livre pra implementar infraestrutura.
Exato! Geralmente nao existe o conceito de repositorios no dominio a ser modelado. Quando usamos repositorios no dominio ele ja tem uma responsabilidade atribuida.
Eu editei esse post em que citei o livro pra deixar mais claro o contexto da discussao. Eu nao quis dizer que não é dominio, apenas que eles ja têm responsabilidades pre-estabelecidas, independente de qual seja o dominio.
Apesar de nao ser um pecado capital ter regras de negocio em repositorios eu procuro evitar, você nao?
[quote=Maurício Linhares]E como é que elas são entidades fracas?
Se elas existem e são buscadas sem o aggregate, deveriam ter um repositório só pra elas.[/quote]
Não são apenas Root Entities que podem ser persistidos. Entidades menores e até mesmo Value Objects podem ter seu estado persistido. Apenas os elementos roots devem ser recuperados do repositório de forma a fazer parte do negócio, os outros devem ser acessados apenas mediante navegação da associação… beleza, estou de acordo com isso. Contudo, existem particulariedades que fazer um repositório apenas para recuperar uma listagem de todos objetos de valor, que são utilizados exclusivamente para uma associação específica em um root, acaba sendo burocrático demais … 
[quote=cmoscoso]
Apesar de nao ser um pecado capital ter regras de negocio em repositorios eu procuro evitar, você nao?[/quote]
Não é nem evitar, qual regra um repositório teria? Eu não consigo lembrar de nenhum xemplo de cabeça onde criei um repositório com aluma regra, como eles não existem no mundo real (do domínio) não é natural que tenham regras.
Mas as pessoas que eu converso sobre DDD a maioria nao ve problemas em colocar negocio ali, e geralmente fazem isso… nao há limites para a criatividade humana!
Eu mesmo ja quebrei muita cabeca para entender essa zona cinzenta que existe entre a interface do repositorio e a infraestrutura de fato. Porque a implementacao do repositorio nao é realmente camada de infraestrutura porque depende do dominio e nao parece natural na camada de domínio porque possui codigo de infraestrutura (SQL, DAO, entity manager).
A implementação do repositório pertence à infraestrutura, e não ao domínio. O domínio só conhece a interface; a implementação é injetada de alguma forma na camada de negócios (containers DI, factories, aspectos, etc). Se a implementação do repositório contém X métodos a mais que a abstração, a camada de negócios não sabe nem que esses X métodos existem.
[quote=tnaires]
A implementação do repositório pertence à infraestrutura, e não ao domínio. O domínio só conhece a interface; a implementação é injetada de alguma forma na camada de negócios (containers DI, factories, aspectos, etc). Se a implementação do repositório contém X métodos a mais que a abstração, a camada de negócios não sabe nem que esses X métodos existem.[/quote]
Entao como você faz para implementar um metodo do repositorio que retorna um objeto da domain layer?
Rendimento buscaRendimentoAprovado();
Sua camada de infraestrutura faz um import do objeto de dominio Rendimento?
O simples fato de a implementacao (o que você diz ser camada de infraestrutura) implementar a interface (camada de dominio) ja viola principios basicos da arquitetura e separacao por camadas.
[quote=cmoscoso]Entao como você faz para implementar um metodo do repositorio que retorna um objeto da domain layer?
Rendimento buscaRendimentoAprovado();
Sua camada de infraestrutura faz um import do objeto de dominio Rendimento?[/quote]
Ao meu ver, não há nenhum problema em um DAO por exemplo instanciar objetos da camada de domínio através de Factories. Mas posso estar errado.
Viola por quê? O repositório ( que é abstrato e não sabe nada de persistência - apenas declara os métodos de domínio ) pertence à camada de domínio, e a implementação ( que é concreta e conhece tudo de persistência ) pertence à infra-estrutura, num exemplo claro de inversão de dependências. O acoplamento depende de como você injetará a implementação ( um DAO, por exemplo ) na camada de domínio.
Moscoso, empilhamento de Camadas é algo interessante mas não é um requerimento. Quando Camadas são cross-cutting concerns como persistência, egurança ou distribuição é praticamente impossível (em java ao menos). No caso de persistência esqueça empilhamento, minha primeira mensagem nesta thread foi sobre isso: use Dependency Inversion Principle apenas.
Eu já desencanei do isolamento total faz tempo, estava apenas comentando.
Mas eu gosto de ter a camada de insfraestrutura independente. Pra isso eu crio um modulo de infraestrutura de persistencia, e geralmente ele reside no namespace do dominio. É a tal área cinzenta que havia dito.
E DIP é lei, mas estou falando de camadas e camadas sempre serão empilhadas.
[quote=cmoscoso]
E DIP é lei, mas estou falando de camadas e camadas sempre serão empilhadas.[/quote]
Nao. Alguns autores insistem em Camadas empilahdas mas isso nao eh umr equerimento par ausar o padrao. Camadas sao agrupamentos de componentes com responsabilidade relacionada apenas, podem ser opacas/empilhadas ou nao.
[quote=pcalcado]
Nao. Alguns autores insistem em Camadas empilahdas mas isso nao eh umr equerimento par ausar o padrao. [/quote]
Referências?
É porque “camadas não-empilhadas” me lembra módulos.
Mas cmoscoso, você poderia dar um exemplo de sua “área cinzenta”? Fiquei curioso agora.
com.exemplo.domain - regras de negocio/interface repositorios
com.exemplo.domain.impl - depende de domain e infra
com.exemplo.infra - implementacoes jpa, hibernate, …
POEAA, pagina 17