DDD e Value Objects

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Olá, ainda sobre DDD...
Segundo o exemplo abaixo, onde tem-se um objeto "Perfil", e "Avaliacao" representa um voto de um usuário acerca de um perfil, pode-se entender "Avaliacao" como sendo um VO? E este seria um membro do aggregate "Perfil" ?

public class Perfil extends EntidadeBase implements java.io.Serializable {

private Categoria categoria;
	private Imagem imagem;
	private String nome;
    private Set<Avaliacao> avaliacoesDoPerfil = new HashSet<Avaliacao>(0);

public Perfil() {
	}

@Id
	@GeneratedValue(strategy = IDENTITY)
	@Column(name = "id_perfis", unique = true, nullable = false)
	public Integer obterId() {
		return (Integer) this.id;
	}

public void setarId(Integer id) {
		this.id = id;
	}

@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "id_categoria", nullable = false)
	public Categoria obterCategoria() {
		return this.categoria;
	}

public void setCategorias(Categoria categoria) {
		this.categoria = categoria;
	}

@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "id_imagens", nullable = false)
	public Imagem obterImagem() {
		return this.imagem;
	}
	
	public void setarImagem(Imagem imagem) {
		this.imagem = imagem;
	}

@Column(name = "nome", length = 150)
	public String obterNome() {
		return this.nome;
	}

public void setarNome(String nome) {
		this.nome = nome;
	}

@OneToMany(fetch = FetchType.LAZY, mappedBy = "perfis")
	public Set<Avaliacao> obterAvaliacoesDoPerfil() {
		return this.avaliacoesDoPerfil;
	}

public void setarAvaliacoesDoPerfil(Set<Avaliacao> avaliacoesDoPerfil) {
		this.avaliacoesDoPerfil = avaliacoesDoPerfil;
	}
    //Operações e detalhes ocultados...

}

public class Avaliacao extends EntidadeBase implements java.io.Serializable {

private Perfil perfil;
	private Date dataAvaliacao;
	private String host;
	private float nota;

public Avaliacao() {
	}

@Id
	@GeneratedValue(strategy = IDENTITY)
	@Column(name = "id_avaliacao", unique = true, nullable = false)
	public Integer obterId() {
		return (Integer) this.id;
	}

public void setarId(Integer id) {
		this.id = id;
	}

@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "id_perfis", nullable = false)
	public Perfil obterPerfilAvaliado() {
		return this.perfil;
	}

public void setarPerfilAvaliado(Perfil perfil) {
		this.perfil = perfil;
	}

@Temporal(TemporalType.TIMESTAMP)
	@Column(name = "data_avaliacao", nullable = false, length = 0)
	public Date obterDataAvaliacao() {
		return this.dataAvaliacao;
	}

public void setarDataAvaliacao(Date dataAvaliacao) {
		this.dataAvaliacao = dataAvaliacao;
	}

@Column(name = "host", nullable = false, length = 100)
	public String obterHost() {
		return this.host;
	}

public void setarHost(String host) {
		this.host = host;
	}

@Column(name = "nota", nullable = false, precision = 12, scale = 0)
	public float obterNota() {
		return this.nota;
	}

public void setarNota(float nota) {
		this.nota = nota;
	}
    //Operações e detalhes ocultados...
}

Entendo que Avaliacao seria sim um VO, uma vez que um voto não se altera, apenas exclui ou insere...
O que vcs acham?

Obrigado pela atenção!

This message was edited 1 time. Last update was at 18/07/2009 17:29:35

Olá

O atributo id da classe Avaliação indica que ela não é um VO, uma vez que ela tem identidade. Isso significa que se você gravar duas avaliações com a mesma data, o mesmo host e a mesma nota, elas terão identidades diferentes, pois os valores do campo id para as duas instâncias serão diferentes. Isso que você falou de adicionar e excluir mas não alterar se refere à imutabilidade de um VO, que não é requerida apesar de recomendada. Além do mais, como sua classe pode ser imutável com setters para todos os atributos?

Ainda, isso não é um aggregate porque instâncias da classe agregada - Avaliação - podem ser criadas ou removidas por quaisquer outras classes do sistema que não o root do aggregate.

EDIT - como questionamento final, qual o ganho que você obtém ao fazer com que todas as suas classes de domínio herdem de EntidadeBase?

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Olá Tarso, obrigado!

Bem, em relação a EntidadeBase, todas as entidades herdam dela, pois, pretendo manter as operações em comum entre esses objetos nessa classe, e também para facilitar a implementação de um Repository genérico.
Quanto aos VOs, acho que ainda não consegui captar...
Por exemplo, no meu tópico anterior vc citou:

Na maioria dos casos os VOs terão uma tabela correspondente, mas não é regra.

Ainda não entendi como um VO pode ter uma tabela mas sem um identificador...
Você teria um exemplo aí disso?

Desculpe a ignorância, mas estou ainda tentando engatinhar com isso...

Obrigado pela paciência...

spinow wrote:Ainda não entendi como um VO pode ter uma tabela mas sem um identificador...

Se houver uma tabela correspondente ao VO, haverá sim um identificador, mas ele não se propaga para seu modelo de domínio.

Vejamos um exemplo: temos as classes Pessoa e UF abaixo.

A classe Pessoa é uma entidade. Duas pessoas podem ter o mesmo nome e serem do mesmo estado, mas certamente possuirão cpfs diferentes.

A classe UF é um VO. Duas instâncias que contenham a sigla "RN" são iguais. Aqui você pode ou não tomar a decisão de manter seus estados em uma tabela; caso isso ocorra, simplesmente crie uma tabela cuja chave primária é a sigla do estado e pronto, pois como você falou não é correto criar uma tabela sem chave primária - apesar de ser perfeitamente possível.

Mas perceba que, em seu modelo de domínio, a classe UF continua sem ter identidade. Ela não deixou de ser um VO só porque sua tabela correspondente possui chave primária. Resumindo: os conceitos de identidade no modelo de domínio e no banco de dados são diferentes.

Abraços

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Totalmente esclarecedor meu amigo! Show de bola!

Muito obrigado pela ajuda!

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Tome cuidado ao começar a trabalhar com VOs, tenha o conceito deles super bem definidos. Se for ver, 99% do que vc acha na web sobre eles trata de modelos anêmicos, completamente o contrário do que o DDD propõem.

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Vlw pela dica Bruno!

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Surgiu outra dúvida (por favor, tenham paciência comigo... hehe):

No exemplo do UF, quando eu fosse criar uma Pessoa, eu então teria que ter uma instância de UF.
Caso o UF tivesse esta estrutura:

ou esta:

, ao instanciar um novo objeto UF para ser vinculado a Pessoa, setando sua chave (id ou sigla), isso já não bastaria para saber "quem é o Estado", caracterizando assim um Entity?

vlw!

Não entendi...

Você quer armazenar na classe Pessoa apenas o id do Estado? É isso?

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Se não me engano @Entity denota uma entidade, para Value Objects deve ser usado @Embedded/Embeddable.

Thread.start() Membro desde: 16/07/2009 20:00:33 Mensagens: 27 Offline

Não não...
A questão é a seguinte, eu entendi bem nos exemplos mais triviais, como Endereço, que não se trata de uma tabela no banco (Desculpe, ainda não consegui fazer o tal do "Database não existe..."). O problema é com os VOs que são uma tabela e possuem chave...

No exemplo citado, UF, a sigla sendo sua @Id (também ainda me sinto preso ao ORM...), já não caracteriza sua identidade? Pois, não existem dois Estados com a mesma sigla...

outra dúvida é, como obter uma lista de todos os VOs Estado, uma vez que VO não possui repository?

Desculpe se não estou conseguindo ser muito claro...

Obrigado pela ajuda, Tarso!

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Entidades e Value Objects são conceitos independentes de Repositórios.

Ser uma entidade significa que você é único, não importa que outros objetos tenham os mesmos nomes, os mesmos valores, mesmas datas, mesmos tudo. Cada um é o seu. Claro que para representar dentro de um computador precisamos de algum tipo de identificador, seja ele uma sequence do banco, seja ele o endereço de memória em que o objeto se encontra.

Value Objects são definidos apenas por seus atributos, se dois VOs tem a mesma descrição, eles são o mesmo VO. Para representar, por exemplo, uma UF na base de dados, a própria sigla dela é a chave identificadora dela, assim como qualquer outro atributo pode ser.

Ter IDs ou não, não o fazem ser Entidades ou VOs. Os IDs só servem para a gente guardar esses objetos em algum lugar e ter como buscá-los depois.

spinow wrote:No exemplo citado, UF, a sigla sendo sua @Id (também ainda me sinto preso ao ORM...), já não caracteriza sua identidade? Pois, não existem dois Estados com a mesma sigla...

Como o Bruno falou, os IDs só existem por causa do banco de dados, que não podemos evitar. Se não fosse isso você nem precisaria configurar um ID.

Suponha que você tem duas instâncias de Pessoa que têm o mesmo valor para o atributo nome: "Roberto Carlos". Você pode dizer que essas instâncias representam a mesma pessoa? Claro que não. Pode haver milhares de pessoas com esse mesmo nome por aqui. Nesse caso, o que é que diferencia uma pessoa da outra? A classe deverá ter algum atributo que permita distinguir uma pessoa que possui os mesmos atributos da outra; aqui no Brasil o CPF é adequado para isso.

Agora se você pegar duas instâncias da classe Estado que possuem o valor "SP" para o atributo sigla, você pode dizer que são dois estados diferentes? Não importa qual instância você pegue, ela sempre representará o estado de São Paulo.

Outro exemplo. Você vai pagar uma conta com uma nota de 20 reais. Pra você importa qual é a nota? Uma vez que seja de 20 reais, você pode pagar a conta com qualquer uma, ela pode perfeitamente ser substituída pela outra. Instâncias de VOs são totalmente substituíveis. Voltando ao exemplo dos estados, se uma pessoa nasceu em São Paulo, qualquer instância da classe Estado que possua como valor da sigla "SP" pode ser usada. Entidades não são substituíveis, pois são únicas. Uma pessoa com nome "Roberto Carlos" não pode ser substituída por outra com o mesmo nome, pois elas fatalmente podem representar pessoas diferentes.

spinow wrote:outra dúvida é, como obter uma lista de todos os VOs Estado, uma vez que VO não possui repository?

Ué, por que não? O repositório nem mesmo precisa estar acoplado ao banco de dados. Dependendo dos requisitos, seu repositório pode retornar uma lista fixa de estados.

Claro, isso é muito menos flexível. Mas é só um exemplo que ilustra como um VO pode existir sem ter uma tabela por trás.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

tnaires wrote:

spinow wrote:outra dúvida é, como obter uma lista de todos os VOs Estado, uma vez que VO não possui repository?

Ué, por que não?[/code]

Porque Repository so pode ser usado para recuperar agregados, e o root do agregado tem que ser uma entidade. O spinow tem razão.

Não é verdade que IDs são apenas detalhes de banco de dados. Toda entidade possui um ID com significado para o domínio. O fato do ValueObject que não pertence a nenhum agregado existir numa tabela de banco de dados que é um detalhe de infra que não deveria vazar para o domínio. Usar @Entity num value object você estará fazendo um grande desfavor para sua ubiquitous language.

Na verdade se o domínio precisa obter uma lista de Estados que não pertence a nenhum agregado é sinal que vc precisa de um servico de domínio para retornar objetos Estado (com @Embedded) ou de uma entidade que contém essa lista (Pais por exemplo).

mochuara wrote:Porque Repository so pode ser usado para recuperar agregados, e o root do agregado tem que ser uma entidade.

Então todo VO está necessariamente acoplado a um aggregate?

mochuara wrote:Não é verdade que IDs são apenas detalhes de banco de dados.

É verdade, quis dizer chaves primárias e acabei falando IDs. Perdão.

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