Hibernate e Domain-Driven Design

Que tal uma consultoria!? Nem só de idealismo vive um homem… :wink:

Vc deve isolar. A questão é: vc consegue ?
No seu código de exemplo não ha referencia nenhuma ao hibernate, logo vc já isolou (!).
O que vc quer mais que se diga ?

Ai vc responde: “mas eu configurei todos os attributos tudo usando anotações só que não escrevi no exemplo” . Bom, então já tem uma referencia ao hibernate. Já não está isolado.

Afinal qual é o problema com a palavra “isolar” ? Isolar é manter distancia, não tocar , não ter conhecimento.
Se vc escreve uma virgula que seja na sua classe cliente porque está usando hiberante , então não está isolado. Vc consegue escrever a classe cliente sem assumir que está usando hibernate ?

A sua classe cliente tem algum método de negocio ? coloque ai o codigo.
Se a sua classe Cliente não tem métodos de negocio esta conversa é inútil porque cliente não é objeto de domínio é um DTO. Nota: métodos que lêm coisas do banco não são métodos de negocio.

Quantas vezes é preciso escrever que aquilo não é um ActiveRecord ???
O que faz um objeto ser activo é ter um método save e um load de si mesmos. Ter lazy-loading (que é o nome da tenica que vc está usando ali) não o faz ser ativo. Está claro isso ?!

E eu já lhe disse logo no inicio da thread para esquecer o lazy-loading. E até lhe expliquei como tornar o loading lazy sem escrever isso explicitamente na classe cliente.
O que é que vc não entendeu ?

Parece que andamos à roda sempre da mesma coisa… assim não vamos lá.

sergiotaborda, eu consigo entender perfeitamente quando você diz que ActiveRecord não deve ser levado a sério.

Mas toma cuidado com o que diz. ActiveRecord não tem implementação decente em Java. Não se esqueça de colocar isso nas frases criticando o ActiveRecord.

Dizer que ActiveRecord só funciona para casos simples é um absurdo. ActiveRecord não funciona em Java.

Taz, quanto a ser ActiveRecord ou não, pode ser simples:

class Gato {  // esse é um ActiveRecord
  private ComidaRepository repository;

  Gato(ComidaRepository repository) { ... }

  public List<Comida> getComidaDasUltimasTresSemanas() {
    repository.getComida(this, Period.weeks(3));
  }

  public void salvar() {
    this.repository.salva(this);
  }

  public void remover() {
    this.repository.remove(this);
  }
}

class Gato {  // esse NÃO é um ActiveRecord
  private ComidaRepository repository;

  Gato(ComidaRepository repository) { ... }

  public List<Comida> getComidaDasUltimasTresSemanas() {
    repository.getComida(this, Period.weeks(3));
  }
}

O fato do gato ter ou não as operações de persistência (saber ele mesmo cuidar do seu estado persistente) diz se é ou não um ActiveRecord. O método getComidaDasUltimasTresSemanas() não tem nada a ver com persistencia. Quem chama o metodo num gato, nem sabe se a comida vem de uma List<Comida> ou do banco de dados.

Em ambos os casos, o gato usa um Repositório (que é um conceito de negócio, pertence ao domínio) para recuperar as comidas relacionadas. Mas isso não tem NADA a ver com persistência (portanto não faz com que o gato seja um ActiveRecord), neste caso o Repositório tem a responsabilidade de cuidar das relações entre as duas entidades do domínio: gato e comida.

Mas em uma coisa eu concordo: a diferença em alguns casos é bem sutil e pode até ser discutível.