Domain Model "RICO" x Anêmico

Oi pessoal!!

Estava estudando um pouco sobre os patterns e os anti-patterns do Fowler... e vi o famoso anti-pattern "Domain Model Anêmico", o qual eu usava a bastante tempo e achava "bom".

Realmente li as explicações e concordei, porém não consegui ver uma implementação disso!! Existe muita teoria, e nada de implementação!!

Por exemplo, na aplicação separada em camadas:
1 - Poxa, não vou colocar comandos de persistencia na minha camada de negocios! Lógico que vou fazer uma camada distinta para persistência, mas então minha camada de persistência continuará sendo anêmica ?!
2 - Como vou evitar a referência cíclica entre a camada de negócios e a camada de persistência (business conhecendo a dao e dao conhecendo a business) ?!
3 - Isso não diminuirá a do sistema. Coesão é o quanto uma classe é especializada numa determinada função. Uma classe que tanto trata as regras de negócio como gerencia o estado dos atributos de negócio não é pouco coesa?!
4 - Como implementar esse tão falado Domain Model "perfeito" do Fowler sem ter esses problemas citados.

JavaTeenager Membro desde: 17/07/2007 15:06:34 Mensagens: 161 Offline

cara de uma olhada nesses artigos do Shoes...

http://fragmental.com.br/wiki/index.php/P%C3%A1gina_principal

tem material referente a isso!

abraços

Meu caro, acho que você fez alguma confusãozinha nos conceitos. O Domínio não tem nada a ver com a camada de infra, na qual fica a persistência. O Domínio fica na camada de negócios, onde são mapeados os conceitos de negócio em objetos que colaboram entre si.

O que Fowler quer dizer com modelos anêmicos, é que muitos sistemas não mapeiam os conceitos de negócio em objetos, criam estruturas em uma classe e criam outra classe para manipular essa estrutura, tornando o programa bem procedural, parecido com um programa escrito em C onde você tem um .h com a struct e um .c manipulando esta. Um exemplo classico disso nos nosssos sistemas Java é um sistema onde temos PessoaBo e PessoaVo, ContaCorrenteBo e ContaCorrenteVo. Esses Patterns publicados pela Sun para tentar consertar o problemas do EJB antes do 3.0, fizeram com que virasse um padrão para tudo quanto é tipo de sistema, sem que as pessoas pudessem saber ao certo para que estavam usando isso.

Oi emerson... então cara, eu sei que a persistência não tem a ver com o domínio.... mas de qualquer forma é preciso montar um VO para ser persistido na camada de "infra-estrutura".

Eu queria saber como se implementa isso sem ter que criar um VO pra "enviar" pra persistência...

Já disse que a teoria é linda... só ainda não vi nada concreto... todo mundo critica o modelo anêmico, mas não mostram uma implementação real do modelo conotado como "correto".

Aquele UML que tem nos artigos da fragmental não mostra como será feita a persistência.

Ou seja, como é esse Domain Model no MUNDO REAL ?? essa é minha dúvida.

gibaholms wrote:Oi emerson... então cara, eu sei que a persistência não tem a ver com o domínio.... mas de qualquer forma é preciso montar um VO para ser persistido na camada de "infra-estrutura".

Eu queria saber como se implementa isso sem ter que criar um VO pra "enviar" pra persistência...

Não precisa montar VO, persista o objeto do Domínio. Adicione ele no repositório (ou o seu DAO, não importa).

Além disso, acho que você ainda está com o conceito antigo da Sun sobre VO. Esse pattern mudou para TO [Core J2EE] ou DTO [PEAA, Fowler].
Estes links vão te ajudar:
http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
http://martinfowler.com/eaaCatalog/valueObject.html

gibaholms wrote:Aquele UML que tem nos artigos da fragmental não mostra como será feita a persistência.

O Artigo não é meu mas já lí. Ele explica o real sentido de utilizar os antigos VOs, que agora são DTOs ou TOs. Sem a real necessidade deles utilize POJOs e seja feliz. Alias, sinceramente acho que você não leu o artigo direito.

gibaholms wrote:Ou seja, como é esse Domain Model no MUNDO REAL ?? essa é minha dúvida.

http://martinfowler.com/eaaCatalog/domainModel.html
http://en.wikipedia.org/wiki/Domain_model
http://www.infoq.com/minibooks/domain-driven-design-quickly

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Você tem que se aprofundar no "conjunto da obra" e não apenas em uma parte dela para realmente entender como se contruir um modelo não anêmico.

Como já citado aqui, Domain Model é apenas o fragmento do sistema responsável pelas entidades de negócio e seus comportamentos.

Sua interação com o resto do sistema é apoiada em outras práticas. Seu modelo não deixa de ser rico quando vc delega para algum Gateway (PoEAA - Fowler) realizar algum serviço de infraestrutura, ou quando tal feito é realizado pela camada de aplicação (DDD - Evans) isolando seu Domain Model.

Especificamente, sobre persistência em modelos ricos, procure por "Repository" catalogado por Evans e Fowler... fonte de milhares de discussões aqui no GUJ.

Boa sorte

Notícias, artigos e o maior fórum brasileiro sobre Java