http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net
Algo que tem incomodado ultimamemente é a utilização do chamado "Modelo Anêmico". Já melhoramos um pouco, mas algumas classes continuam bastante anêmicas, hehehe. Por exemplo, imaginem que eu quero inserir um objeto da classe [b]Pessoa[/b]. Hoje a requisição é recebida por uma classe [b]Action[/b] (ex: PessoaAction), que encaminha os dados para uma classe que costumam chamar de "Service" (ex: PessoaService) que valida as informações e chama uma classe estática que fica responsável pela persistência dos objetos com o Hibernate. O maior problema que eu vejo nessa solução é que as regras de negócio da classe [b]Pessoa[/b] estão em [b]PessoaService[/b]. Na minha visão, PessoaService continuaria existindo apenas para diminuir a dependência do Struts, mas ao invés de validar as regras e chamar a classe estática para persistência, ela apenas invocaria o método (não estático) [b]Pessoa.inserir()[/b].

Para tornar isso realidade tenho que solucionar uma questão. Como poderia fazer com que minha classe de modelo [b]Pessoa[/b] conseguisse persistir os objetos sem criar uma dependência? Eu andei lendo um pouco sobre injeção de dependências, não sei se este é o caminho da solução. Se alguém souber de algo e puder ajudar eu ficarei muito feliz! :D

Muito obrigado, amigos, bom fim de semana pra vcs!]]> http://www.guj.com.br/prepost/75388/396399/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396399/fugindo-do-modelo-anemico GMT Algo que tem incomodado ultimamemente é a utilização do chamado "Modelo Anêmico". Já melhoramos um pouco, mas algumas classes continuam bastante anêmicas, hehehe. Por exemplo, imaginem que eu quero inserir um objeto da classe [b]Pessoa[/b]. Hoje a requisição é recebida por uma classe [b]Action[/b] (ex: PessoaAction), que encaminha os dados para uma classe que costumam chamar de "Service" (ex: PessoaService) que valida as informações e chama uma classe estática que fica responsável pela persistência dos objetos com o Hibernate. O maior problema que eu vejo nessa solução é que as regras de negócio da classe [b]Pessoa[/b] estão em [b]PessoaService[/b]. Na minha visão, PessoaService continuaria existindo apenas para diminuir a dependência do Struts, mas ao invés de validar as regras e chamar a classe estática para persistência, ela apenas invocaria o método (não estático) [b]Pessoa.inserir()[/b].

[/quote]

Pessoa.inserir é o padrão ActiveRecord. Usar esse padrão não é uma boa. Continue usando a sua classe estática (acho que quiz dizer metodo estático) para fazer a persistencia ou seja arrojado e crie um DAO. Regra de negocios de pessoa... qual seria um exemplo de regra de negocios de pessoa ?
Se essa regra usar entidades que não estão no grafo de pessoa então vc precisa de um Service. Mova para Pessoa todas as regras que dependem apenas do objeto pessoa e daqueles que estão no seu grafo e deixe em service aqueles que usam outras entidades. O nome do service deve ser [objetivo]Service ou [acção]Service e não [entidade]Service por isso foque nas acções/objetivos e agrupe os que são comuns ]]> http://www.guj.com.br/prepost/75388/396403/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396403/fugindo-do-modelo-anemico GMT http://www.guj.com.br/prepost/75388/396405/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396405/fugindo-do-modelo-anemico GMT Exatamente, não me expressei bem, quis dizer que tenho uma classe composta apenas por métodos estáticos.

[quote=sergiotaborda]Regra de negocios de pessoa... qual seria um exemplo de regra de negocios de pessoa ? Se essa regra usar entidades que não estão no grafo de pessoa então vc precisa de um Service. Mova para Pessoa todas as regras que dependem apenas do objeto pessoa e daqueles que estão no seu grafo e deixe em service aqueles que usam outras entidades.[/quote]
Na verdade o sistema não tem classe Pessoa, foi apenas um exemplo. O que você chamou de grafo são os relacionamentos de dependência? Eu não acho legal essa idéia de passar as coisas para uma classe Service, pois o conhecimento sobre o negócio está deixando as classes de modelo. Por exemplo, eu não posso excluir um objeto da classe Cliente se ele está relacionado a um objeto da classe Pedido. Eu gostaria de um modelo que eu pudesse olhar e entender ali todas as regras de negócio, evitando que elas fiquem espalhadas. Este exemplo com Cliente/Pedido que citei é trivial, mas existem regras que envolvem estados dos objetos que são bem mais complexas, essa descentralização tem trazido problemas.

[quote=sergiotaborda]Pessoa.inserir é o padrão ActiveRecord. Usar esse padrão não é uma boa.[/quote]
Eu não sabia que isso não era uma boa. Se não estou enganado isso é usado no queridinho do momento Ruby On Rails, não sei se traz algum problema que eu ainda não tenha conseguido visualizar. Você pode exemplificar algo nesse sentido?

Abraços e muito obrigado pela sua resposta!]]> http://www.guj.com.br/prepost/75388/396422/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396422/fugindo-do-modelo-anemico GMT Se você tenta modelar os objetos de forma que façam sentido para o negócio, os métodos das classes tem que fazer sentido também.]]> http://www.guj.com.br/prepost/75388/396433/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396433/refugindo-do-modelo-anemico GMT [quote=sergiotaborda]Regra de negocios de pessoa... qual seria um exemplo de regra de negocios de pessoa ? Se essa regra usar entidades que não estão no grafo de pessoa então vc precisa de um Service. Mova para Pessoa todas as regras que dependem apenas do objeto pessoa e daqueles que estão no seu grafo e deixe em service aqueles que usam outras entidades.[/quote]
Na verdade o sistema não tem classe Pessoa, foi apenas um exemplo. O que você chamou de grafo são os relacionamentos de dependência?
[/quote]

Não. Em O não ha "relacionamentos", ha objetos contendo objetos. Isso é um grafo.

[quote]
Eu não acho legal essa idéia de passar as coisas para uma classe Service, pois o conhecimento sobre o negócio está deixando as classes de modelo. Por exemplo, eu não posso excluir um objeto da classe Cliente se ele está relacionado a um objeto da classe Pedido. Eu gostaria de um modelo que eu pudesse olhar e entender ali todas as regras de negócio, evitando que elas fiquem espalhadas. Este exemplo com Cliente/Pedido que citei é trivial, mas existem regras que envolvem estados dos objetos que são bem mais complexas, essa descentralização tem trazido problemas.
[/quote]

Cuidado com o que vc pensa.
1) CRUD não é regra de negocio. Isto que fique bem claro. "Não posso excluir o cliente quando ele tem pedidos" é um regra de consistencia de dados e não de dominio/negocio.
2) A relação entre cliente e pedido não forma um grafo fixo.

[code]Cliente c = ...
Set<Pedidos> pedidos = c.getPedidos() ;
[/code]

pode parecer que c contém a coleção de pedidos, mas não. Aquele método de dominio que mostra a relação entre cliente e pedido
apenas consulta o repositorio de pedidos por aqueles cujo cliente é c. Não ha necessidade do cliente andar com uma lista de pedidos às costas.
Ainda mais quando essa lista muda a qq momento.

DDD dix-lhe para criar o método getPedidos() e outros do mesmo tipo e isso que é uma regra de dominio. Isto não tem nada a ver com CRUD.
O crud do pedido é independente do crud do cliente.
]]> http://www.guj.com.br/prepost/75388/396596/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396596/fugindo-do-modelo-anemico GMT Se você tenta modelar os objetos de forma que façam sentido para o negócio, os métodos das classes tem que fazer sentido também.[/quote]
Entendo o que você diz, faz sentido. [:(]
Estou começando a acreditar que o que temos hoje no sistema não é tão ruim, embora seja necessário melhorar algumas coisas.

[quote=sergiotaborda]Não. Em O não ha "relacionamentos", ha objetos contendo objetos. Isso é um grafo.
(...)
2) A relação entre cliente e pedido não forma um grafo fixo.[/quote]
Eu realmente fiquei confuso com essa concepção de grafo, não entendi. Imagine que uma classe [b]Pedido[/b] possui um atributo [b]Cliente[/b]. Isso não pode ser visto como um relacionamento entre as duas classes? Seguindo o que você falou, Cliente pertence ou não ao grafo de Pedido? Se você tiver um link falando sobre grafos nesse contexto eu gostaria de ver, não consegui entender bem.

[quote=sergiotaborda]
[code]Cliente c = ...
Set<Pedidos> pedidos = c.getPedidos() ;
[/code]

pode parecer que c contém a coleção de pedidos, mas não. Aquele método de dominio que mostra a relação entre cliente e pedido
apenas consulta o repositorio de pedidos por aqueles cujo cliente é c. Não ha necessidade do cliente andar com uma lista de pedidos às costas.
Ainda mais quando essa lista muda a qq momento.[/quote]
Agora que eu não entendi mesmo. Necessidade de andar com uma lista? Mas isso não está relacionado a forma como você implementa? Também não entendi o porquê de Cliente não conter uma coleção de pedidos, porque o que você descreveu, para mim, indica claramente que existe um relacionamento bidirecional entre as duas classes.

Abraços a todos!]]> http://www.guj.com.br/prepost/75388/396610/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396610/refugindo-do-modelo-anemico GMT A classe Pessoa deve conter regras do tipo que elas tem no mundo real. Disso consiste a abstração.
Por exemplo, Pessoa.pedirMercadoriaParaEstoque(String mercadoria). Já o codigo pertinente a salvar uma Pessoa ou não vai no PessoaRepository.

Mas aí fica uma outra dúvida, é bom chamar o repository direto da Action do Struts?]]> http://www.guj.com.br/prepost/75388/396642/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396642/refugindo-do-modelo-anemico GMT A classe Pessoa deve conter regras do tipo que elas tem no mundo real. Disso consiste a abstração.
Por exemplo, Pessoa.pedirMercadoriaParaEstoque(String mercadoria). Já o codigo pertinente a salvar uma Pessoa ou não vai no PessoaRepository.

Mas aí fica uma outra dúvida, é bom chamar o repository direto da Action do Struts?[/quote]

Cabe a decisão da equipe, contudo repository faz parte do negócio. Qualquer livro de DDD você vai ler a recomendação de isolar camada de negócio de camada de aplicação (Actions, ManagedBeans, etc), geralmente isso é o mais indicado. ]]> http://www.guj.com.br/prepost/75388/396644/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396644/refugindo-do-modelo-anemico GMT
...

Cabe a decisão da equipe, contudo repository faz parte do negócio. Qualquer livro de DDD você vai ler a recomendação de isolar camada de negócio de camada de aplicação (Actions, ManagedBeans, etc), geralmente isso é o mais indicado. [/quote]

Concordo contigo em isolar o domain da camada de application. E isso não é nem do DDD só, vem dos Patterns J2EE mesmo e está sendo reforçado no DDD. Mas aí o cara cai na utilização de um Service pra fazer esse isolamento (É o que eu uso, ou utilizo uma Entity chamando o repository). Alguém pode postar um exemplo de como vocês fazem?]]> http://www.guj.com.br/prepost/75388/396647/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396647/refugindo-do-modelo-anemico GMT http://www.guj.com.br/prepost/75388/396650/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396650/refugindo-do-modelo-anemico GMT
Mas aí caímos no Entity.insert() falado acima. Só que a logica dentro de Entity.insert() seria uma simples chamada ao repository.

A verdade é que o modelo anêmico está mais relacionado com o que a classe não faz do que com o que ela faz. Caso ela esteja fazendo coisas que não estão no seu escopo, aí o problema é de classes obesas, e não anêmicas.

Mas essas discussões são sempre ótimas para reafirmar o conceitos que temos e a forma que fazemos as coisas.]]> http://www.guj.com.br/prepost/75388/396661/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396661/refugindo-do-modelo-anemico GMT
Não necessariamente. Um repository não faz apenas CRUD, eles realizam buscas necessárias para os entities. *Nestes e outros casos* um repository dentro de um entity faz todo sentido do mundo.

Outra situação é ocorrer em meio de um processamento de método de negócio, um objeto (um Aggregate) persistir outro objeto (composto pelo Aggregate), ou até mesmo requisitar sua própria persistencia. A grande diferença é o contrato de sua assinatura, ela não faz sentido ter um save ou persist. Mas se em meio a sua lógica for necessário guardar sua informação no repositorio, não te pq não faze-lo.

Normalmente, mas não por regra, os CRUDs acabam por cair nas costas de um Service.


]]> http://www.guj.com.br/prepost/75388/396676/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396676/refugindo-do-modelo-anemico GMT [quote=sergiotaborda]Não. Em O não ha "relacionamentos", ha objetos contendo objetos. Isso é um grafo.
(...)
2) A relação entre cliente e pedido não forma um grafo fixo.[/quote]
Eu realmente fiquei confuso com essa concepção de grafo, não entendi. Imagine que uma classe [b]Pedido[/b] possui um atributo [b]Cliente[/b]. Isso não pode ser visto como um relacionamento entre as duas classes? Seguindo o que você falou, Cliente pertence ou não ao grafo de Pedido? Se você tiver um link falando sobre grafos nesse contexto eu gostaria de ver, não consegui entender bem.
[/quote]

Pedido contém um atributo do tipo Cliente. Sim. Cliente pertence ao grafo de Pedido e eu faço pedido.getCliente().
O cliente do pedido reponde a "Quem fez o pedido?"
Mas se eu quiser responder a "Quais pedidos o cliente fez?" ai eu uso cliente.getPedidos().
Com estas duas coias eu posso responder a "Que pedidos o cliente que fez este pedido, fex?" apenas com pedido.getCliente().getPedidos().
Isto é uma regra de dominio.

O facto de pedido ter um atributo ter um cliente sim pode ser encarado como um relacionamento entre as duas entidades, mas esse relacionamento é "virtual" ou seja, não existe um objeto Relacionamento que tenha um referencia a cada um. (Poderia haver, mas normalmente não ha). O que ha é uma Referencia de pedido a cliente , mas não de cliente a pedidos. Quando executa Cliente.getpedidos() vc está executando uma regra de negocio que é muito mais complexa que pedido.getCliente(). cliente.getPedido() implica num raciocinio "procura os pedidos onde o cliente é this"

Em codigo :

[code]class Pedido {

Cliente cliente; // attributo. Cliente pertence ao grafo fixo de Pedido
}

class Cliente {

// não ha nenhuma referencia ao Set<Pedido>

public Set<Pedido> getPedidos(){

return PedidoRepository.findByClient(this);
}

}[/code]


Embora do lado de fora pareça que Set<Pedidos> existe dentro de cliente, ele não existe de fato. Isso é a vantagem de encasulação.
O que tudo isto interessa?
Quando vc salva o pedido , ha um campo na tabela Pedido que diz respeito ao cliente. Logo o sistema tem que averiguar se o cliente está tb salvo. Se não, salva-o ( ou salva-o logo por default e pronto)
Mas quando o sistema salva o cliente ele não salva a coleção de pedidos. Porque ele não salava? porque não ha nenhum atributo desse tipo em cliente.
Então getPedidos() parece igual a getCliente(), mas não são. Mas o objetivo do DDD é exatamente que pareçam, mesmo que internamente não sejam.

[quote]
Agora que eu não entendi mesmo. Necessidade de andar com uma lista? Mas isso não está relacionado a forma como você implementa? Também não entendi o porquê de Cliente não conter uma coleção de pedidos, porque o que você descreveu, para mim, indica claramente que existe um relacionamento bidirecional entre as duas classes.
![/quote]

Se o cliente contivesse um lista de pedidos cada vez que vc salva o cliente salvaria os pedidos e cada vez que retorna um cliente, retorna todos os pedidos tb. Entenda que isso cria um cliclo vicioso. Salvar o pedido salva o cliente que salva o pedido, que salva o cliente ... Claro que a sua ferramente de persistencia pode evitar isso, mas o ponto aqui é que Pedido não pertence ao grafo de cliente. Pedido não especifica o cliente. Mas cliente especifica o pedido. Essa é a diferença.
E não, ninguém anda com uma lista. Sim, depende de como implementa. Mas se vc implementar diferente vai ter muita dor de cabeça por causa do paradoxo que falei antes.

Em termos de banco de modelo E-R existe um relacionamento bidirecional, mas em termos de DDD e OO não. Isso porque não é a mesma coisa vc obter pedidos a partir de um cliente e o cliente ter uma [b]referencia[/b] a esses pedidos. E em OO o que conta são as referencias e não os relacionamentos.

Pense assim : vc poderia executar PedidosRepository.findByCliente(Cliente c) sempre que precisasse em qq ponto da aplicação. Mas isso é uma falha de encasulamento. Isso é equivalente a usar o objeto cliente como um DTO e isso é contra a ideia do DDD. É mais claro , e simples , que seja cliente.getPedidos().

Espero ter esclarecido.
]]> http://www.guj.com.br/prepost/75388/396756/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396756/refugindo-do-modelo-anemico GMT
Abraços,]]> http://www.guj.com.br/prepost/75388/396758/fugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/396758/fugindo-do-modelo-anemico GMT
Isso não seria um pouco controverso?

Seguindo o Padrão GRASP Especialista na Informação, poderiamos dizer que: Quem tem os dados deve ser responsável por manipula-los. Com isso, conseguimos um boa divisão de responsábilidades, conseguimos fornecer um bom encapsulamento, evitamos inveja dos dados enfim, conseguimos evitar modelos anêmicos.

Muitas vezes olhando para o Especialista da Informação fiz reflexões parecidas com esta: O objeto Fornecedor conhece seus dados logo seria responsabilidade dele se salvar, assim manteriamos o encapsulamento etc.. etc...

Mas como persistência é um problema de infra vamos voltar lá no mundo de bobject...

reflexões...]]> http://www.guj.com.br/prepost/75388/397168/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397168/refugindo-do-modelo-anemico GMT
Isso não seria um pouco controverso?

Seguindo o Padrão GRASP Especialista na Informação, poderiamos dizer que: Quem tem os dados deve ser responsável por manipula-los. Com isso, conseguimos um boa divisão de responsábilidades, conseguimos fornecer um bom encapsulamento, evitamos inveja dos dados enfim, conseguimos evitar modelos anêmicos.

Muitas vezes olhando para o Especialista da Informação fiz reflexões parecidas com esta: O objeto Fornecedor conhece seus dados logo seria responsabilidade dele se salvar, assim manteriamos o encapsulamento etc.. etc...

Mas como persistência é um problema de infra vamos voltar lá no mundo de bobject...

reflexões...[/quote]
É, Bruno, controverso. Eu entendo os dois lados, não é fácil decidir. Neste momento, eu vejo mais benefícios em fazer com que a classe [b]Fornecedor[/b] saiba como salvar e recuperar seus objetos. Com AspectJ eu vi uma forma bem legal de fazer isso, o código na classe Fornecedor não seria alterado, ela apenas herdaria uma interface.

Como o Bruno falou, reflexões... ]]> http://www.guj.com.br/prepost/75388/397196/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397196/refugindo-do-modelo-anemico GMT Ë puramente uma questão de escolha de design.]]> http://www.guj.com.br/prepost/75388/397228/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397228/refugindo-do-modelo-anemico GMT
Isso não seria um pouco controverso?

Seguindo o Padrão GRASP Especialista na Informação, poderiamos dizer que: Quem tem os dados deve ser responsável por manipula-los. Com isso, conseguimos um boa divisão de responsábilidades, conseguimos fornecer um bom encapsulamento, evitamos inveja dos dados enfim, conseguimos evitar modelos anêmicos.

Muitas vezes olhando para o Especialista da Informação fiz reflexões parecidas com esta: O objeto Fornecedor conhece seus dados logo seria responsabilidade dele se salvar, assim manteriamos o encapsulamento etc.. etc...
[/quote]

Isso é uma falácia.
O fornecedor realmente tem conhece os seus dados, mas não conhece a localização da persistência. Entenda que essa localização pode mudar e ver variada. Se o fornecedor conhecer essa localização ele está puxando para si uma responsabilidade que não lhe cabe. Não é que o forncedor não se possa persistir, é que ele não sabe onde.
Compara com Serializable. Vc pode implementar no objecto um write e um read para substituir a seriaização padrão. Aqui o objeto está chamando para si a responsabilidade de quais dados e em que ordem os vai serializar, mas o processo não é da responsabilidade dele, o Objectstream que sabe a localização e o algoritmo para a serialização.

No caso do fornecedor ele não tem meios de sobreecrever as operações crud, mas tb não precisa, já que tudo é feito pelo sistema de persistência.

Então sim, existem uma forte necessidade de separar a persistencia da entidade porque ela não detalhes da persistencia e como tal não pode ter essa responsabilidade.

O encapsulamento não tem nada a ver com o problema já que tanto em entidade.save() como em algo.save(entidade) ninguem está vendo como o save acontece realmente.

]]> http://www.guj.com.br/prepost/75388/397245/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397245/refugindo-do-modelo-anemico GMT [quote=sergiotaborda]Não. Em O não ha "relacionamentos", ha objetos contendo objetos. Isso é um grafo.
(...)
2) A relação entre cliente e pedido não forma um grafo fixo.[/quote]
Eu realmente fiquei confuso com essa concepção de grafo, não entendi. Imagine que uma classe [b]Pedido[/b] possui um atributo [b]Cliente[/b]. Isso não pode ser visto como um relacionamento entre as duas classes? Seguindo o que você falou, Cliente pertence ou não ao grafo de Pedido? Se você tiver um link falando sobre grafos nesse contexto eu gostaria de ver, não consegui entender bem.
[/quote]

Pedido contém um atributo do tipo Cliente. Sim. Cliente pertence ao grafo de Pedido e eu faço pedido.getCliente().
O cliente do pedido reponde a "Quem fez o pedido?"
Mas se eu quiser responder a "Quais pedidos o cliente fez?" ai eu uso cliente.getPedidos().
Com estas duas coias eu posso responder a "Que pedidos o cliente que fez este pedido, fex?" apenas com pedido.getCliente().getPedidos().
Isto é uma regra de dominio.

O facto de pedido ter um atributo ter um cliente sim pode ser encarado como um relacionamento entre as duas entidades, mas esse relacionamento é "virtual" ou seja, não existe um objeto Relacionamento que tenha um referencia a cada um. (Poderia haver, mas normalmente não ha). O que ha é uma Referencia de pedido a cliente , mas não de cliente a pedidos. Quando executa Cliente.getpedidos() vc está executando uma regra de negocio que é muito mais complexa que pedido.getCliente(). cliente.getPedido() implica num raciocinio "procura os pedidos onde o cliente é this"

Em codigo :

[code]class Pedido {

Cliente cliente; // attributo. Cliente pertence ao grafo fixo de Pedido
}

class Cliente {

// não ha nenhuma referencia ao Set<Pedido>

public Set<Pedido> getPedidos(){

return PedidoRepository.findByClient(this);
}

}[/code]


Embora do lado de fora pareça que Set<Pedidos> existe dentro de cliente, ele não existe de fato. Isso é a vantagem de encasulação.
O que tudo isto interessa?
Quando vc salva o pedido , ha um campo na tabela Pedido que diz respeito ao cliente. Logo o sistema tem que averiguar se o cliente está tb salvo. Se não, salva-o ( ou salva-o logo por default e pronto)
Mas quando o sistema salva o cliente ele não salva a coleção de pedidos. Porque ele não salava? porque não ha nenhum atributo desse tipo em cliente.
Então getPedidos() parece igual a getCliente(), mas não são. Mas o objetivo do DDD é exatamente que pareçam, mesmo que internamente não sejam.

[quote]
Agora que eu não entendi mesmo. Necessidade de andar com uma lista? Mas isso não está relacionado a forma como você implementa? Também não entendi o porquê de Cliente não conter uma coleção de pedidos, porque o que você descreveu, para mim, indica claramente que existe um relacionamento bidirecional entre as duas classes.
![/quote]

Se o cliente contivesse um lista de pedidos cada vez que vc salva o cliente salvaria os pedidos e cada vez que retorna um cliente, retorna todos os pedidos tb. Entenda que isso cria um cliclo vicioso. Salvar o pedido salva o cliente que salva o pedido, que salva o cliente ... Claro que a sua ferramente de persistencia pode evitar isso, mas o ponto aqui é que Pedido não pertence ao grafo de cliente. Pedido não especifica o cliente. Mas cliente especifica o pedido. Essa é a diferença.
E não, ninguém anda com uma lista. Sim, depende de como implementa. Mas se vc implementar diferente vai ter muita dor de cabeça por causa do paradoxo que falei antes.

Em termos de banco de modelo E-R existe um relacionamento bidirecional, mas em termos de DDD e OO não. Isso porque não é a mesma coisa vc obter pedidos a partir de um cliente e o cliente ter uma [b]referencia[/b] a esses pedidos. E em OO o que conta são as referencias e não os relacionamentos.

Pense assim : vc poderia executar PedidosRepository.findByCliente(Cliente c) sempre que precisasse em qq ponto da aplicação. Mas isso é uma falha de encasulamento. Isso é equivalente a usar o objeto cliente como um DTO e isso é contra a ideia do DDD. É mais claro , e simples , que seja cliente.getPedidos().

Espero ter esclarecido.
[/quote]

Uau. Excelente explicação Sérgio.
Com código ainda que facilita bastante o entendimento.]]> http://www.guj.com.br/prepost/75388/397254/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397254/refugindo-do-modelo-anemico GMT O fornecedor realmente tem conhece os seus dados, mas não conhece a localização da persistência. Entenda que essa localização pode mudar e ver variada. Se o fornecedor conhecer essa localização ele está puxando para si uma responsabilidade que não lhe cabe.[/quote]
Concordo plenamente, sem ressalvas.

[quote=sergiotaborda]Não é que o forncedor não se possa persistir, é que ele não sabe onde.[/quote]
E se fizermos isso com DI? A classe [b]Fornecedor[/b] continua sem saber como persistir, isso seria injetado nela. Isso é uma boa solução?]]> http://www.guj.com.br/prepost/75388/397257/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397257/refugindo-do-modelo-anemico GMT Se você acredita que estas assinaturas de métodos faz sentido estar nas entidades, sua equipe e Expert Domain concordarem com você, tudo bem.

Eu simplemente acho que um EntidadeRepository.add(entidade) resolve o problema, sem ter que comprometer a modelagem da Entidade a.k.a. ActiveRecord desnecessário.

Isso não é falácia, é ponto de vista.
]]> http://www.guj.com.br/prepost/75388/397307/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397307/refugindo-do-modelo-anemico GMT Uma pergunta: nesse caso, como vc faz a validação dos dados do objeto?

Cria um método entidade.validar() e chama dentro do EntidadeRepository.add(entidade)?

[]'s

Rodrigo C. A.
]]> http://www.guj.com.br/prepost/75388/397352/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397352/refugindo-do-modelo-anemico GMT [quote=sergiotaborda]Não é que o forncedor não se possa persistir, é que ele não sabe onde.[/quote]
E se fizermos isso com DI? A classe [b]Fornecedor[/b] continua sem saber como persistir, isso seria injetado nela. Isso é uma boa solução?[/quote]

Se vc usar injeção de dependência vc continua tendo dependência. Apenas não é vc que seta as referencias dos objetos manualmente. Não muda nada em termos de responsabilidade.
Se vc injetar um objeto que tenha essa responsabilidade de saber onde persistir vc estará implicitamente retirando essa responsabilidade de Fornecedor. Ai fica pior, a responsabilidade é de outro objeto mas vc está forçando o uso atravéz de Fornecedor como um façade. Ou seja se vc tiver


[code]class Fornecedor {

DAO dao ; // injetado pela infraestrutura

// atributos

public void save (){
dao.save(this);
}
}[/code]

Vc está usando Fornecedor como um Façade para DAO só porque vc gostaria de escrever:

[code]fornecedor.save();[/code]

Porque não fazer logo:
[code]
dao.save(fornecedor);[/code]

Em vez de complicar a vida com ActiveRecord ?

Eu concordo com a afirmação do Lezinho:

[quote=Lezinho]
Eu simplemente acho que um EntidadeRepository.add(entidade) resolve o problema, sem ter que comprometer a modelagem da Entidade a.k.a. ActiveRecord desnecessário.
[/quote]

]]> http://www.guj.com.br/prepost/75388/397353/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397353/refugindo-do-modelo-anemico GMT Isso é uma falácia.
[/quote]

Rs... Engraçada essa afirmação!

Você esta dizendo que um padrão GRASP é uma falácia?

Eu discordo. Acho que os padrões de responsábilidades GRASP nos ajudam a aplicar a base da orientação a objeto, ainda mais se tratando do especialista da informação que é o mais importante.

[quote=sergiotaborda]
O fornecedor realmente tem conhece os seus dados, mas não conhece a localização da persistência. Entenda que essa localização pode mudar e ver variada. Se o fornecedor conhecer essa localização ele está puxando para si uma responsabilidade que não lhe cabe. Não é que o forncedor não se possa persistir, é que ele não sabe onde.
[/quote]

Ele não precisa saber onde se persitir... é só criar uma indireção e utilizar injeção de dependencia...

[quote=sergiotaborda]
O encapsulamento não tem nada a ver com o problema já que tanto em entidade.save() como em algo.save(entidade) ninguem está vendo como o save acontece realmente.
[/quote]

Acho que você esta enganado. Há uma quebra de encapsulamento! Sorte que a quebra é feita com reflexão ou aspectos... Senão teriamos que fazer fazer manutenção com espingarda!

]]> http://www.guj.com.br/prepost/75388/397371/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397371/refugindo-do-modelo-anemico GMT Seguindo o Padrão GRASP Especialista na Informação, poderiamos dizer que: Quem tem os dados deve ser responsável por manipula-los. Com isso, conseguimos um boa divisão de responsábilidades, conseguimos fornecer um bom encapsulamento, evitamos inveja dos dados enfim, conseguimos evitar modelos anêmicos.

Muitas vezes olhando para o Especialista da Informação fiz reflexões parecidas com esta: O objeto Fornecedor conhece seus dados logo seria responsabilidade dele se salvar, assim manteriamos o encapsulamento etc.. etc...

Mas como persistência é um problema de infra vamos voltar lá no mundo de bobject...

reflexões...[/quote]

Manipular os dados não significa persisti-los mas aplicar invariantes e regras de negócio. Isso que torna o modelo não anêmico.

Eu vejo que no DDD essa coisa de persistir a si mesmo é desestimulada. Eu (digamos entity) posso até usar o repositório para ler a persistencia e resolver alguma regra de negocio, ou seja, eu [b]conheco[/b] a persistencia (por meio do repositorio), mas eu nao me persisto porque não é minha [b]responsabilidade[/b], eu faco parte de uma [i]unit of work[/i].
]]> http://www.guj.com.br/prepost/75388/397442/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397442/refugindo-do-modelo-anemico GMT Uma pergunta: nesse caso, como vc faz a validação dos dados do objeto?

:arrow: Cria um método entidade.validar() e chama dentro do EntidadeRepository.add(entidade)?

[]'s

Rodrigo C. A.
[/quote]

A questão da validação é relativa a cada caso.
Se a validação é sobre invariantes simples do contrato, eu utilizo Hibernate Validator (para contratos nulos, tamanho de campos, datas futuras ou passadas, regex, etc)

Ex:

[code]
@Entity
public class Entidade{

@Future
private Date apenasDataFutura

@NotNull
private Object objetoQualquerNaoNulo

...

}
[/code]


Se a validação para um contrato for quanto a permissão de papeis do usuário, eu uso o Seam com Drools :
[code]
//somente usuarios com o papel `admin` pode acessar este método
@Restrict("#{s:hasRole('admin')}")
public void meuMetodoDeNegocio(Object obj){
....
}
[/code]

... agora se o contrato for algo que exige mais do negócio, entao eu evito colocar validações nos clientes e implemento no próprio negócio (por exemplo, quando um Entity faz um pedido ao Repository, quem vai verificar o contrato é o Repository).

Eu tento manter o código o mais limpo possível dos contratos, mas quando não é possível não se pode fazer muita coisa.

]]> http://www.guj.com.br/prepost/75388/397491/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397491/refugindo-do-modelo-anemico GMT Isso é uma falácia.
[/quote]

Rs... Engraçada essa afirmação!

Você esta dizendo que um padrão GRASP é uma falácia?
[/quote]

Não. Estou dizendo que a frase a seguir é uma falácia.

[quote=brunohansen]] O objeto Fornecedor conhece seus dados [b]logo[/b]seria responsabilidade dele se salvar, assim manteriamos o encapsulamento etc.. etc...
[/quote]

'A' conhecer seus dados não implica em que é responsabilidade de 'A' fazer algo com eles.
Se formos por esse caminho eu poderia dizer que:

"O DefaultTableModel do Swing conhece seus dados logo ele teria a responsabilidade de se mostrar na tela."

Acho que é simples de entender que esse tipo de construção lógica é uma falácia.]]> http://www.guj.com.br/prepost/75388/397497/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397497/refugindo-do-modelo-anemico GMT
Porque?

Porque você não chega no mundo real e pede pelo telefone pra um fornecedor inserir dados, mas pede pra um fornecedor preencher um formulário. Portanto, Fonecerdor.preencheFormulario() seria cogitável, porém a melhor forma é colocar o metodo de inserção num repository ou num service.

Pense num repository como uma classe que administra uma coleção de objetos de um determinado tipo. Se você que adicionar um fornecedor a uma coleção (DB por exemplo), tem que adicionar pelo repository.

Nomes importam muito na abastração. Aliás acho que é isso que diferencia arquitetos de desenvolvedores. A capacidade de abstrair.

PS.: Você não é obrigado a utilizar DDD, mas não diga que está utilizando quando na verdade não está.]]> http://www.guj.com.br/prepost/75388/397526/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/397526/refugindo-do-modelo-anemico GMT
No caso, as classes de persistência são mais Especialistas na Informação para a tarefa de inserir no BD.
E você teria um problemas de Coesão Baixa e Alto Acoplamento, além de uma lógica similar fique duplicada em muitas classes persistêntes.

Por exemplo: uma venda pode informar seu total, mas ela não saber onde persistir (penso que ela nem deveria saber da existência do DAO), o DAO sabe onde persistir um objeto, e traze-lo de volta.

Estou com saudades do tempo que eu fazia tudo da minha cabeça. IMHO.

]]> http://www.guj.com.br/prepost/75388/636094/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/636094/refugindo-do-modelo-anemico GMT Isso não é controverso?
[/quote]

[quote=sergiotaborda]
Isso é uma falácia.
[/quote]

[b]

Nem falácia nem controverso!

Não se pode confundir um objeto de invenção pura, com o Data Transfer Objects.

Um objeto não deve persistir a si mesmo; isso viola o principio de Separação de Interesses.

O padrão Separação de Interesses tem prioridade sobre o Especialista na Informação.

Existe uma prioridade nos padrões; Primeiro Grasp (básicos) depois GoF, e todo padrão tem contra-indicação...

[/b]]]> http://www.guj.com.br/prepost/75388/672750/refugindo-do-modelo-anemico http://www.guj.com.br/prepost/75388/672750/refugindo-do-modelo-anemico GMT