Por isso geralmente acontece do service ficar enorme. Aí recorremos novamente a AOP ou DI.
Criar entities com repositorio via factory pode ser uma alternativa interessante.
Nao entendi porque o Service ficaria enorme. Afinal, voce nao precisa ter um Service, nem deveria, e sim dividir por conceitos de negocio.
Acho que perdi algo no seu argumento, nao entendi a relacao.
[quote=pcalcado]Nao entendi porque o Service ficaria enorme. Afinal, voce nao precisa ter um Service, nem deveria, e sim dividir por conceitos de negocio.
Acho que perdi algo no seu argumento, nao entendi a relacao.[/quote]
Eu falo de Service como facade.
Vocês estão falando de servico de negocio?
É o velho conflito da Service Layer versus Domain Services… algumas vezes podem ser os mesmos, outras não …
Se você utiliza Seam por exemplo, você pode invocar diretamente do front-end (Páginas, Facelet, GWT …)suas Entities, Repositories, Services, controlar o fluxo de páginas via jPDL, tudo sem necessitar obrigatoriamente de Façades para interagir com o modelo.
Em outros casos algum intermédio é necessário, para por exemplo exibir alguma mensagem informativa (não de exceptions, para isso o Seam cuida sozinho com poucas configurações em xml). Neste caso de intermédio, não se trata de Services de domínio e não devemos confudir como tal.
Bem, eu nao concordo que eles possam ser os mesmos. Um reside dentro do dominio o outro nao.
Eu concordo que nem sempre é necessario uma service layer.
Assim como eu acho que nem sempre é necessario um domain service apenas para acessar repositorios.
[quote=Lezinho]Se você utiliza Seam por exemplo, você pode invocar diretamente do front-end (Páginas, Facelet, GWT …)suas Entities, Repositories, Services, controlar o fluxo de páginas via jPDL.
[/quote]
Pode claro, mas IMO, não deve! 
ps: pode me chamar de purista.
Na prática Carlos, isto pode acontecer.
Já tive projetos com requisito de expor todo o negócio em EJB 3.0.
Para isso, Façades estavam por todo o sistema. Mas como ela era POJO (EJB 3), em muitos casos servia perfeitamente como um Domain Service (tanco conceitualmente como na aplicabilidade), em outros ela fazia apenas a ponte da camada de serviço. Não é sempre que isso acontece, mas quando você trabalha com EJB3 e Seam, é normal você se deparar com esta situação.
[quote=cmoscoso][quote=Lezinho]Se você utiliza Seam por exemplo, você pode invocar diretamente do front-end (Páginas, Facelet, GWT …)suas Entities, Repositories, Services, controlar o fluxo de páginas via jPDL.
[/quote]
Pode claro, mas IMO, não deve!
ps: pode me chamar de purista.[/quote]
E pq não devo?
O que eu perco invocando um repository em uma página, como:
<h:dataTable value=#{clienteRepositorio.clientesComDivida} ...>[quote=Lezinho][quote=cmoscoso]
Bem, eu nao concordo que eles possam ser os mesmos. Um reside dentro do dominio o outro nao.
Eu concordo que nem sempre é necessario uma service layer.
Assim como eu acho que nem sempre é necessario um domain service apenas para acessar repositorios.
[/quote]
Na prática Carlos, isto pode acontecer.
Já tive projetos com requisito de expor todo o negócio em EJB 3.0.
Para isso, Façades estavam por todo o sistema. Mas como ela era POJO (EJB 3), em muitos casos servia perfeitamente como um Domain Service (tanco conceitualmente como na aplicabilidade), em outros ela fazia apenas a ponte da camada de serviço. Não é sempre que isso acontece, mas quando você trabalha com EJB3 e Seam, é normal você se deparar com esta situação.[/quote]
Concordo em relação à visão que o cliente tem do dominio. Pra ele a fachada, quando existe, é o dominio.
Mas quem implementa o dominio sabe diferenciar o domain service da service layer.
[quote=Lezinho][quote=cmoscoso][quote=Lezinho]Se você utiliza Seam por exemplo, você pode invocar diretamente do front-end (Páginas, Facelet, GWT …)suas Entities, Repositories, Services, controlar o fluxo de páginas via jPDL.
[/quote]
Pode claro, mas IMO, não deve!
ps: pode me chamar de purista.[/quote]
E pq não devo?
O que eu perco invocando um repository em uma página, como:
<h:dataTable value=#{clienteRepositorio.clientesComDivida} ...>
[/quote]
Caso os requisitos do cliente do repositorio sejam alterados para que ele acesse o dominio remotamente você terá um trabalho maior para evitar que seus objetos sejam distribuidos.
É necessário cautela caso você nao tenha certeza se isso pode acontecer.
[quote=cmoscoso]
Mas quem implementa o dominio sabe diferenciar o domain service da service layer.[/quote]
Mesmo se o Domain service é a própria fachada remota para um cliente (dispensando a service Layer neste caso , já que um simples metadado resolve tudo)?
Bom, a tecnologia foi simplificada que muitas vezes um próprio elemento do Domínio (como um service), pode assumir um outro papel sem afetar o próprio modelo (só lamento que as anotações em java são tão dependentes), é isso.
[quote=cmoscoso]Caso os requisitos do cliente do repositorio sejam alterados para que ele acesse o dominio remotamente você terá um trabalho maior para evitar que seus objetos sejam distribuidos.
É necessário cautela caso você nao tenha certeza se isso pode acontecer.[/quote]
Eu posso distribuir diretamente o repositório, ele é uma interface. Em caso mais extremos, o método pode ser refatorado caso o cliente radicalize seus requisitos, de maneira a otimizar as chamadas remotas. Caso utiliza-se Façade, o trabalho seria o mesmo, com o acrescimo da possibildade do cliente nunca mudar o requisito de distribuição (foram raros os projetos que ví onde o cliente exigiu: (Agora eu quero que isso seja um EJB).
[quote=Lezinho]
Mesmo se o Domain service é a própria fachada remota para um cliente (dispensando a service Layer neste caso , já que um simples metadado resolve tudo)?
Bom, a tecnologia foi simplificada que muitas vezes um próprio elemento do Domínio (como um service), pode assumir um outro papel sem afetar o próprio modelo (só lamento que as anotações em java são tão dependentes), é isso.[/quote]
Aí agente volta à diferença entre os conceitos. Se todo seu dominio se resume a apenas esse domain service, ok, mas geralmente um dominio é maior do que isso, o domain service representa um conceito do seu negocio, ao contrario da facade que representa todo o seu dominio atraves de uma interface simplificada.
No caso de remoting, um domain service é um objeto, uma service layer nao, ou seja, domain service não deveria ser distribuido. A velha historio de que nao devemos distribuir nossos objetos.
Uma fachada que representa todo meu Domínio? Acho que estou entendendo errado, ou você sugere mesmo uma Mega Booster Super Façade que engloba todo meu domínio? Sinceramente eu acharia isso perigoso, em vista que meu domínio pode não ter uma distribuição homogenia por um único meio.
Concordo que as façades são interfaces simples para o cliente que podem agregar serviços e diminuem a carga na distribuição, isso é fato e utilizo desta forma quando necessário, mas no mínimo aplicar ele por caso de uso. Nisso, usando DDD, em determinados momentos você pode notar que alguns Domain services agregam (não necessariamente e não comumente) atividades que podem compreender perfeitamente a um Caso de Uso, e isso faça sentido para o domínio… neste caso ele é tanto o objeto de domínio que oferece serviços relacionados a entidades ou repositorios como pode ser uma fachada remota (é só anotar… afinal de contas pode compreender um Use Case).
Concordo e apoio, eu prefiro distribuir a aplicação do que os componentes (cluster web+business no lugar de EJBs clusterizados). Mas requisitos são requisitos… se um cliente quer que exponha um serviço de forma remota para determinado caso de uso, ele terá… da forma que quiser (webservice SOAP, Rest, JSon, EJB, etc).
editado: acho que o Phillip não precisa esclarecer nada
Sei la, caso você possua um Super Mega Booster Dominio… 
Acho que esta havendo uma confusão entre Domain Models e Domain Objects.
Quando me refiro ao domínio, estou me referindo ao todo do domínio e não uma única classe (apenas para ser claro) e nesta caso uma única façade, é no mínimo, “exótico”.
[quote=Lezinho]Acho que esta havendo uma confusão entre Domain Models e Domain Objects.
Quando me refiro ao domínio, estou me referindo ao todo do domínio e não uma única classe (apenas para ser claro) e nesta caso uma única façade, é no mínimo, “exótico”.[/quote]
Sim, estamos falando da mesma coisa.
Você tem razão, clientes não devem depender de interfaces que eles nao utilizam mas meu ponto era que apesar de as vezes a facade nao se fazer necessaria os conceitos continuam sendo independentes.
Eu apenas acho simplista dizer nessas situacoes que sao conceitos iguais, a nao ser do ponto de vista do cliente que as utiliza.
Ficamos combinado assim? :thumbup:
Mas é isso mesmo Carlos. :thumbup:
O conceito não muda (o Domain Service tem seu papel e a Service/Application Layer tem outro). Apenas achei relevante mencionar que algumas vezes podemos ver classes acumulando (por razões de pontos de vista distintos da aplicação) mais de um papel e normalmente isto recai sobre os Services mesmo.
Só voltando um pouco a dúvida inicial
Uma outra solução já que você está se utilizando do Spring seria utilizar a anotação @configurable nas tuas entidades, dá uma olhada aqui, isso deve te ajudar, http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html
Abraços.
A alternativa seguinte seria uma possibilidade para o caso simples em que o repositorio possui uma implementação única… se não for o caso, poderia ser utilizado um Registry.
Nesta implementação, o hibernate chama o construtor privado para criar o objeto, que então se encarrega de instanciar sua dependência. Para o caso de instanciação via operador new, o que pode ser útil para testes de unidade, fica a cargo do cliente a criação do objeto num estado consistente, o que inclui a injeção da dependência com o repositório (ou então coloca-se isso numa Factory).
@Entity
public class Conta {
// outros atributos
@Transient
private Repository repository;
// construtor privado usado apenas pelo Hibernate para instanciar o objeto
private Conta() {
repository = new DaoQueImplementaRepository();
}
public Conta(Repository repository) {
this.repository = repository;
}
// outros metodos
}
Isso resolve o problema proposto? ou cria outros problemas?
Abraços