ronildobraga wrote:Eu nao achei pratica essa solução, e se eu mudar a logica de acesso a dados, por exemplo: Hoje eu uso hibernate mas amanha eu gostaria de usar JDBC, seguindo o Active Record eu teria de configurar novamente todos os objetos de dominio, nao achei muito inteligente nao

Rafael Nunes wrote: No próprio livro Fowler diz que active record é uma boa solução para sistemas que não tenham uma lógica de negócio muito complexa, tipo CRUDs, e sugere que para domínios com relacionamentos mais complexos, seja utilizado alguma forma de Data Mapper, como DAO por exemplo.
O exemplo que eu dei utiliza as duas estratégias, porém ao invés de o objeto de domínio conter a lógica de acesso a dados, ele delega essa responsabilidade para um Data Mapper.

Fabio Kung wrote:Pessoal, não vamos misturar duas discussões né?

Domain Model x BO + DTO é uma coisa.
ActiveRecord (pessoa.save()) x DataMapper (dao.save(pessoa) / repositorio.store(pessoa)) é outra!

ronildobraga wrote: Mas eu acho que isso nao vem ao caso, o que importa é que uma Pessoa tem que possuir um repositorio e a Pessoa deve ser responsavel pela acoes de persistir um objeto do tipo pessoa ! correto ?

ronildobraga wrote:Eu so me pergunto como ficaria isso mapeado no hibernate, eu teria um Pessoa.hbm.xml referenciando o objeto de dominio e nao mais a um VO ?

ronildobraga wrote:

felipec wrote:
Nós não estamos usando mais VO nem BO. Estamos usando um objeto de domínio para cumprir o papel do VO e do BO.

Entendi, obrigado por corrigir.
Eu so me pergunto como ficaria isso mapeado no hibernate, eu teria um Pessoa.hbm.xml referenciando o objeto de dominio e nao mais a um VO ?

Rafael Nunes wrote: (...)
E particularmente, já ouvi bastante esta questão de 'e se eu trocar de banco', 'e se eu trocar de mecanismo de persistência', 'e se eu trocar o SO do meu servidor'), mas na prática nunca vi e nem ouvi falar disso, (...)

ronildobraga wrote:
1)Eu entendo que o objeto de dominio seja a Pessoa, se colocarmos a funcao salvar dentro do repositio e a funcao salvar necessitar de logica, a logica ficaria fora do dominio, a nao ser que o objeto de dominio seja composto por Pessoa + Repositorio, e por isso eu usei composição pois uma pessoa contem um repositorio.

sergiotaborda wrote:
Portanto, se a "função salvar transação" precisa de uma logica suplementar antes de persistir a trnasação, isso fica dentro do Serviço.

Poderiamos argumentar que o serviço não deveria receber entidades, mas isso é outra conversa que não interessa agora.

Eu acho que vc fragmentou a objeto de dominio novamente, o seu servico esta se comportando como uma classe de negocio, vc so mudou de nome.

Lendo uma parte do artigo novamente eu frizo o seguinte:
Um modelo rico traduz o mundo real para software da maneira mais próxima possível, ao utilizar classes de dados separadas das classes de lógica esta vantagem é simplesmente jogada fora. No mundo real não existe lógica de um lado e dados de outro, ambos combinados forma um conceito.

GutomCosta wrote:
Para isto faz se necessário um Service.
Imagine o exemplo da transação bancária.

Um objeto Conta, representa a instancia de uma Conta em um banco. Onde ficaria o Serviço de transferência entre 2 contas ?
Em um Service.

Ele vai instanciar as 2 contas e passar o valor de uma pra outra.
Observe que não estamos colocando responsabilidades referentes ao objeto Conta no Service. Ele apenas organiza os passos da execução e delega as responsabilidades para os objetos de domínios.

ronildobraga wrote:

sergiotaborda wrote:
Portanto, se a "função salvar transação" precisa de uma logica suplementar antes de persistir a trnasação, isso fica dentro do Serviço.

Poderiamos argumentar que o serviço não deveria receber entidades, mas isso é outra conversa que não interessa agora.

Eu acho que vc fragmentou a objeto de dominio novamente, o seu servico esta se comportando como uma classe de negocio, vc so mudou de nome.
.

sergiotaborda wrote:
O ActiveRecord é um padrão mencionado em muitos lugares e tem o seu lugar ao sol em determinados usos (DataSet é um exemplo). Mas refere-se a record (registro) e em DDD uma entidade não é vista como um registro porque a persitência é abstraida e portanto existe uma incompatibilidade natural entre ActiveRecord e DDD.

sergiotaborda wrote:

ronildobraga wrote:

sergiotaborda wrote:
Portanto, se a "função salvar transação" precisa de uma logica suplementar antes de persistir a trnasação, isso fica dentro do Serviço.

Poderiamos argumentar que o serviço não deveria receber entidades, mas isso é outra conversa que não interessa agora.

Eu acho que vc fragmentou a objeto de dominio novamente, o seu servico esta se comportando como uma classe de negocio, vc so mudou de nome.
.

Como o GutomCosta já elucidou não foi isso que eu fiz.
Vc precisa de um terceiro "ser" que manipula os objetos do dominio. Porquê?
Imagine um banco verdadeiro no tempo em que não havia computadores.
Contas eram apenas livros e transferencias eram apenas numeros escritos nesses livros. Se as contas eram livros (objectos inanimados) e transferencias era a escrita de numeros quem escrevia os numeros nos livros ? O escriturário. Ele prestava um serviço importante. Ele tinha que garantir que eram colocados os numeros certos nas contas certas e que a operação era atómica (ou o dinheiro era transferido ou não era. sem mais hipoteses) Quando a operação não era atomica ou as contas não eram as que deveriam acontecia um erro.

Em software. Conta é um entidade, o dinheiro é um valor e o responsável por manipular tudo isto é o serviço. Repare que serviço é ainda da camada de dominio. Ele é o cara que entende o que ha a ser feito, e sabe como fazer. No softtware o serviço é responsável por iniciar uma transação (aqui transação JTA) alterar os valores nas contas e fazer o commit. Repare que esta operação não pode ser responsabilidade da conta porque a conta não sabe o que uma transacção entre contas é ( da mesma forma que um livro não sabe o que um escriturário é).
Mas tem mais detalhes ... na realidade uma transacção bancária não é uma operação entre contas é :
1) verificação de saldo disponivel
2) verificação de limite
3) o lançamento atómico de dois movimentos pareados (partidas obradas) um numa e um noutra.
Que em codigo seria mais ou menso assim

transfere (Conta a , Conta b , Dinheiro m ) throws TransferException{ JTATransaction T = ... try { T.begin(); // a conta tem salso suficiente para pagar ? if (a.limiteSaque () < m){ // o limite depende do saldo e do credito do cliente, que por sua vez //depende de outras coisas. Tudo isso é responsabilidade do objeto Conta throw TransferException("Salso insuficiente"); } Transferencia t = new Transferencia (a,b,m , Data.hoje()); t.executa(); Repository.store(t); T.commit(); } catch (TransferException e) { T.rollback(); throw e; } } Tranferencia { public void executa (){ // tira de a MovimentoConta ma = new MovimentoConta(a, m.times(-1) ,b , data); // da a b MovimentoConta mb = new MovimentoConta(b, m, a , data); Repository.store (ma); Repository.store (mb); } }

A aplicação (a camada de aplicação) chamará o serviço passando os parametros necessários e nunca verá a logica do dominio. Ou seja, o servlet passa a responsabilidade ao serviço (da mesma forma que o atendente do balcão passava ao escriturário)

A "logica de negocio" está na realidade distribuida entre os objectos do dominio , cada uma coma a sua responsabilidade e não mais do que essa.
É preciso deixar claro que o Serviço não é apenas uma mera fachada, ele é o cara que o resto do mundo vê (é o atendente no balcão)
Objetos como Transferencia , MovimentoConta tb existem e é necessário ter um historio deles. Eles são entidades, possuem dados , estado, mas possuem tb tomadas de decisão. Por outro lado, eles existem porque ha que separar a responsabilidade dentro das proprias entidades do dominio.
Conta é apenas um agrupador, o saldo é alterado pelos movimentos de conta , que forma o extrato da conta e portanto têm datas associadas a eles. E cada movimento na sua conta causa um movimento numa outra conta de alguém (partida-dobrada). Se continuar esmiuçando o problema encontrará muito mais entidades necessárias. Se pensar en outros dominios - controle de estoque , por exemplo - verá que algumas entidades se repetem, mas têm papeis diferentes. E tudo isso é a complexidade do dominio que a DDD visa simplificar ao abusar das capacidades oferecidas pela OO.

---

Quanto ao ActiveRecord. Muito simples: na prática não funciona. A razão é simples: quebra de responsabilidade. Os livros não se guardam a si mesmos nas estantes : os objetos de dominio tb não se devem guardar a si mesmos.
Se tentar usar ActiveRecord de uma forma mais gerenciável ,como vc fez, delegando ao repositorio dentro de pessoa, vai acabar com um monte de cdogio repetido, desnecessário, pois chamar o repositorio directamente dá no mesmo e na prática tem mais vantagem (como dilimitar melhor o controlo o commit e o roolbak da persitencia, etc...)

O ActiveRecord é um padrão mencionado em muitos lugares e tem o seu lugar ao sol em determinados usos (DataSet é um exemplo). Mas refere-se a record (registro) e em DDD uma entidade não é vista como um registro porque a persitência é abstraida e portanto existe uma incompatibilidade natural entre ActiveRecord e DDD.

eliziario wrote:
(...)mesmo assim, no mundo real, não conheci ainda nenhum país roxo. Da mesma maneira, em uma aplicação Orientada a Objeto, as atribuições de responsabilidades e os papéis exercidos por cada classe não visam a uma "cópia" do mundo real, mas à obediência à uma série de princípios fundamentais que tem finalidades específicas muito concretas de engenharia.

Então, pode ser ridículo no mundo real que uma conta corrente "credite-se um DOC", mas pode fazer todo o sentido do mundo isso (conta::recebe_doc) em uma aplicação OO, uma vez que Conta é o Information Expert definitivo quando se trata de receber um DOC.

De saída, eu ganho em coesão, e também diminuo o acoplamento,

o que não é o caso do seu código, coisa que podemos comprovar facilmente ao ver que seria muito difícil escrever Unit Tests para seu exemplo.

Outro ponto é que você confunde Serviço com Facade. Embora possam parecer coisas similares, não são. Um Facade expõe um interface simplificada para um subsistema complexo, mas ainda expõe operações em termos de objetos nativos de uma aplicação (por exemplo, se eu faço um Facade para JavaMail, eu tenho uma interface com parâmetros e retornos que ainda são tipos pertencentes ao namespace original de java mail). Já um serviço expõe uma operação de um processo de negócios desacoplando as duas pontas.

sergiotaborda wrote:
Poderiamos argumentar que o serviço não deveria receber entidades, mas isso é outra conversa que não interessa agora.

Não vou nem comentar ainda a mistura de código de transação com código de negócios. Também é lamentável que em pleno 2007 ainda tenha gente que use controle de transação de maneira programática e não declarativa, isso realmente me dá muito desgosto.

Sinceramente, acho que você deveria ler o livro do Evans, e o Object Design da Wirfs-Brock. Depois de ler os dois, leia Refactorings do Fowler pra consertar esse seu código aí em cima.