DDD e JPA - Onde vão as annotations?

Programação Arquitetura
#1

Pessoal,

talvez eu tenha entendido errado algum conceito do DDD, mas eu procurei em muitos lugares, inclusive no GUJ e não achei nenhuma resposta simples para minha pergunta. Com certeza em algum lugar tem a resposta e talvez seja tão trivial que ficou perdida no tempo.

Eu entendo um pouco sobre DAOs e sobre Repositories, mas e as Entities?
Minha classe de Domain terá as regras de negócio e chama o repository para operações (como um service, certo?). O Repository pode executar algumas regras pertinentes a coleções de entities e chama o DAO quando necessário. O DAO precisa obter um objeto do Banco e no caso de um JPA da vida, deve utilizar um pojo com as anotações de JPA.

Mas aí é que fica minha dúvida. As anotações vão na Entity (falando em entity de Domain) ou vão em classes Java “replicadas” na camada de persistência. Caso sim, então eu tenho dois POJOs, um representando o Domain e outro simplesmente para a Persistência.

Pergunto isso porque não gosto da idéia de anotações no meu Domain. Minha classe de Domain não compila sem os jars do JPA.

Abração a todos…

#2

tem um tópico aqui no GUJ que acho q vai tirar sua dúvida…

http://www.guj.com.br/posts/list/67988.java

#3

Duplicar nem pensar… não existe motivos para isso, ainda mais se falando de POJOS.
Se a Entity JPA é POJO e seu Entity DDD é POJO, então os objetos são identicos.

Metadados são simplesmente metadados.

#4

Talvez seja interessante utilizar o JPA com xml ao invés dos annotations. Isso para que o seu modelo não fique amarrado a forma que ele será persistido na base de dados. Mas não acho que seja grave utilizar annotations em seus entities e value objects. Só depende do quão purista você é, rsrs… Não é por que tem annotations que você não pode persistir as entidades utilizando jdbc.

#5

Em outras palavras, depende o quanto chato você quer ser… hehe. Seja um cara legal com sua equipe, use anotações :D.

#6

na verdade a escolha é sua, contanto que vc entenda que não fique ambos…ou um ou outro…no meu caso uso bean com anotações…não acho poluído não…

#7

Bom, primeiramente, obrigado pelas opiniões.

Mas ainda fica uma questão. Eu posso usar uma entity anotada com jdbc na unha, mas a questão é outra. Se meus domains tem que ser POJO, penso que ele não pode ter dependencias.

Acho que a dúvida seria a seguinte:

Se um POJO é suposto ser uma classe que não dependa de nenhuma API para executar, como uma entity JPA anotada seria um POJO?
Imagine que se eu anoto um POJO com a anotaao @Entity eu sou obrigado a fazer import javax.persistence.Entity e isso me obriga a levar o persistence.jar junto com o POJO para onde ele for. Será que ele ainda é um POJO?

Sei que é meio polêmico, mas quero saber com o pessoal tá usando isso no escopo de Domain Driven Design

#8

Anotações são apenas informações jogadas ao vento, não são códigos.
No caso do JPA, sua classe continua sendo POJO se apenas for anotada, mas deixa de ser se você utilizar EntityManager dentro dela (por isso use a abstração oferecida por um Repository).

Uma classe anotada não muda de comportamento, não ganha novas características nem nada, quem infere isso são os manipuladores das anotações… esses sim não são POJOS.

Levar os jars legados é um fato. Mas nada que uma refatoração não resolva. O melhor de tudo, a refatoração vai ser muito simples e sem possibilidades de erros em execução, pois as anotações não atribuem comportamentos inesperados… tudo que vc for pegar de erro será em tempo de compilação (importações, etc).

Eu utilizo algumas Entities JPA como entidades do DDD sem dor na consciência. :wink:

#9

Bom senso… bom senso… bom senso… desenvolvimento de software se resume a bom senso!

#10

É talvez seja um pensamento muito purista, hoje tenho utilizado com as annotations nas entities mesmo. Mas seria ótimo não precisar fazer isso.
Alias, consigo isso com frameworks que não são baseados em annotations. Acho que essa seria a solução para domains que são distribuidos como uma lib, para utilização em JEE, e JME ao mesmo tempo. Ou simplesmente manter dois projeto separados, um para JEE e um para JME.

De qualquer forma, acho que o rodrigo tem razão. Utilizar de bom senso resolve bastante coisa.

#11

O problema eh que metadados (annotations) acabam por criar uma outra ‘dimensao’ nos seus objetos. Minha dica eh:

  • use o que for mais simples
  • nao perca muito tempo viajando sobre annotations ao inves de fazer seu trabalho, eh confuso mesmo
  • nao espalhe as anotacoes de infra pelas classes o quanto puder mas sem radicalismos

A forma com que os metadados sao usados em Java eh pessima. Metadados deviam fazer tagging apenas.

#12

Que risco você enxerga nas anotações da JPA e EJB3, Phillip?

Tenho criado algumas anotações minhas nos meus projetos. Você acha isso prejudicial de alguma forma também?

#13

Também estou criando as anotações JPA nas entidades e EJB3 nos repositórios!

Vocês vêem algum tipo de problema nisto?

Grato.

#14

[quote=Lezinho]Anotações são apenas informações jogadas ao vento, não são códigos.
No caso do JPA, sua classe continua sendo POJO se apenas for anotada, mas deixa de ser se você utilizar EntityManager dentro dela (por isso use a abstração oferecida por um Repository).[/quote]
O que tem a ver ter um atributo de instância com ser um POJO ?

#15

Não vejo a utilização de annotations nas entidades como problema dependendo do projeto. Levando em consideração que o objetivo do DDD é criar um domínio e que este pode ser reaproveitado em outros projetos independente da base de dados, então acho bom não poluir o código com anotações específicas do JPA. Até por que não seria legal depender de um jar do JPA para compilar suas classes.

Enfim… quais são e quantos sãos os ambientes que o seu domínio terá que atuar? Sei lá… acho que ainda fica valendo o bom senso… rsrs…

#16

[quote=emerleite][quote=Lezinho]Anotações são apenas informações jogadas ao vento, não são códigos.
No caso do JPA, sua classe continua sendo POJO se apenas for anotada, mas deixa de ser se você utilizar EntityManager dentro dela (por isso use a abstração oferecida por um Repository).[/quote]
O que tem a ver ter um atributo de instância com ser um POJO ?[/quote]

O termo quando foi cunhado por Fowler, tinha como objetivo dar um nome para classes Java simples, aquelas que não tinham necessidade de estender nem implementar nada de frameworks em específico que lhe rotulassem algo . Porém o termo é apenas uma referência, não é uma regra… mas isso é gosto particular. Tem gente que chama POJO de Bean e esta super bem com isso, outras pessoas acham que JavaBeans é apenas a definição de componentes para GUIs & RADs, etc.

Eu particularmente não chamo classes que dependem da infraestrutura de frameworks que lhe ditam como deve ser seu comportamento, de POJO.

#17

Pois é, você tem razão quanto a isso mas esse problema é que agente mesmo critica pois tinha gente aqui que chamava Repositório de DAO em diversas discussões do GUJ dizendo que eram a mesma coisa e que se sentiam bem chamando assim.

Eu concordo com você que o termo é só uma referência e eu já havia lido o texto do Fowler, porém o mais aceito na nossa comunidade para POJO e as principais referências tem mais a ver com a não necessidade da classe em obedecer contratos de fameworks do que o conteúdo interno da mesma.

Em fim, eu queria só saber por que você tinha dito isso.

#18

Eu uso Annotations. Eu sou muito mais feliz depois do Java 1.5 com suas Annotations.

Quem me conhece sabe que detesto xml para configurar e introduzir comportamentos no código. As Annotatins acabaram com isso, um bom exemplo de bom uso delas é o Hibernate e o JPA.

Então eu anoto diretamente minhas Entitys com as Annotations JPA ou Hibernate.

#19

Pessoal, não consigo ver o porque de não utilizar anotação JPA em minhas entidades!!
Alguém poderia passar alguns motivos?

#20

Gostei do camaradinha ai que disse pra ter BOM SENSO!

Tudo vai do projeto que você está trabalhando…

1- Qual a finalidade?
2- Sua entidades serão usadas somente neste projeto?
3- Haverá mesmo a necessidade de outras aplicações usarem estas entidades?
4- Tem certeza que vão usa-las mesmo?
5- Certeza absoluta?
6- Essas aplicações não vão usar JPA?
7- Certeza que não vão?

Então, cara, depende do projeto que você está trabalhando, do ambiente de desenvolvimento e execução das aplicações. É bom senso!

Haverá casos que usar anotações JPA serão tiro no pé. Outros que serão a salvação! Porque, meu chapa, configurar arquivos XML é um saco! E a possibilidade de erro aumenta de verdade…

Não dá pra ser xiita em desenvolvimento de software. O lance é: Resolva o problema do seu cliente da melhor forma!

E outra coisa: Faça o mais fácil; não se preoculpe com 100% dos problemas que podem acontecer num futuro distante, da ordem de 1%. Pense no agora e no daqui a pouquinho, não no daqui a 2 anos. Muita coisa muda!

Se o que alguém definiu como técnica XPTO serve pra você, ótimo! Se não serve 100%, tente adaptar para a sua necessidade. Não se a adaptação não for viável, mude para a técnica OTPX.

O lance é: Não é o seu a necessidade de software do seu cliente que tem que se adequar à técnica XPTO, mas sem a técnica XPTO te ajudar a atender 100% das expectativas do seu cliente.

Agrade o cliente com resultados 100% positivos, não às técnicas que deixam o seu cliente apenas 80% feliz.

Entregue o software que o seu cliente quer. Com as funcionalidades que ele quer.

Software funcionando e de qualidade total, este é o lema!

É o que eu penso…

Abraço!