Rodrigo Allemand

A peça chave do DDD é a Entidade (Entity).

Entidade é um objeto com um significado para o domínio sendo modelado e que possui uma identidade.

Diagrama de Classe extraido do Modelo

No exemplo dado no decorrer da série de post, basicamente, estas seriam as nossas entidades. Repare que todas as classes possuem uma identidade (o campo ID de cada classe). Isso define uma Entidade: a sua identificação única!

Modelo de dados extraido do Diagrama de Classes

Pensando em um modelo relacional, basicamente, cada entidade representa um registro de uma tabela e as suas referências e dependências. Mas preste a atenção: um modelo relacional é diferente de um modelo de entidades, já que existem diferenças em cada mundo. Veja, por exemplo, a tabela Workflow: não existe referencia a ela como uma classe, mas existe uma coleção, dentro da entidade de Status que referencia esta associação.

DTO x TO x VO x Entidade x Pojo x JavaBean

Vc já ouviu falar de DTO (Data Transfer Object), correto?
E de TO (Transfer Object)?
E de VO (Value Object)?
E de POJO (Plain Old Java Object)?
E de Java Bean?

Se vc acha que é tudo a mesma coisa, vc está enganado!

TO foi citado pelo grupo Core J2EE Patterns inicialmente e foi desenhado para ser usado quando aplicações precdisam se comunicar com EJBs, reduzindo a quantidade de métodos a serem chamados.

DTO segue um proncípio parecido, só não cita EJB e foi descrito por Martin Fowler.

Básicamente, TO e DTO são a mesma coisa, um monte de campos com um bando de métodos acessores (Get e Set) para trafegar informação entre dois “extremos”.

Fowler ainda vai adiante e escreve:

Data Transfer Object is one of those objects our mothers told us never to write. It’s often little more than a bunch of fields and the getters and setters for them. The value of this usually hateful beast is that it
result you need to reduce the number of calls, and that means that you need to transfer more data with each d to procall. One way to do this is to use lots of parameters. However, this is often awkwaronly a single value.often impossible with languages such as Java that return The solution Mels How It Works In many ways, amore than a bun
allows you to move several pieces of information over a network in a single call?a trick that’s essential for
tributed systems.

Já o padrão VO é como se fosse um DTO imutável, ou seja um objeto que mantem o seu valor no decorrer da sua vida. O número 5 sempre vai ser 5. Quando vc muda o 5 pra 6, ele deixa de ser o número 5 e vira o numero 6. Número neste caso é um objeto de valor, um é diferente do outro. Em Java, String, Date, todos os Number. Normalmente

Fowler define Value Object como:

A small simple object, like money or a date range, whose equality isn’t based on identity.

VO não tem identidade, tem valor!

Já o POJO, cunhado por Martin Fowler e cia, são objetos simples. São aqueles objetos que não enxtendem ou implementan ninguem. Não dependem de nenhuma atividade externa. São objetos simples que utilizam somente códigos “nativos de Java”.

E Java Bean? Bem, Java Bean é uma especificação! É ela que diz que as classes devem começar com letra maiúscula, os métodos em minúscula, os getX, setX e isX da vida..

Resumindo:

• Pojo são simples objetos puramente Java;
• JavaBean é uma especificação;
• DTO = TO = Objeto pra transferência de informação;
• VO é um DTO que mantem o seu estado
• Entidade é um objeto que tem uma identidade em um domínio.

Até!

Comente e Recomende!