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.
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.
[quote=gibaholms]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…[/quote]
Não precisa montar VO, persista o objeto do Domínio. Adicione ele no repositório (ou o seu DAO, não importa).
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.
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.
