DDD - Value Object

Posso estar errado, mas não vejo problema em você ter um VO e uma tabela correspondente a ele. No caso, eu criaria a classe Tag contendo apenas um atributo contendo a própria tag, que seria também a chave primária da tabela.

Mais esquecendo o banco de dados. Eu tenho um objeto que ao meu ver é um V.O e pode ser associado a alguns artigos no meu site, por exemplo. Quero poder persistir esse objeto e carregar ele e o count dele pra poder criar meu tagcloud. Mais pra criar o meu tagcloud eu preciso poder carregar somente os objetos tag sem associação com nenhum outro objeto e neste caso eu teria de ter uma forma de carrega-lo no caso um repositório e repositórios só podem existir para aggregates o que não é o meu caso. Eu sei que posso tornar meu objeto tag um entity mais nao sei se este objeto é uma entity pra mim não é. Como resolvo isso?

Onde você viu isso? E como você gerencia o ciclo de vida de uma entidade comum se não for através de um repositório?

Crie um repositório para a classe Tag e seja feliz.

Artigo parece ser seu aggregate. Use o repositorio de artigos para acessar as tags.

Onde você viu isso? E como você gerencia o ciclo de vida de uma entidade comum se não for através de um repositório?

Crie um repositório para a classe Tag e seja feliz.[/quote]

Aires,

Ele leu isso no livro do Eric Evans. A idéia é que uma Entidade só pode ser acessada através de seu Aggregate Root e Aggregate Roots podem ser acessados através de Repositórios.

Uma análise bem superficial com base no que você valou me passa que a tag tem uma identidade única o que a caracteriza como uma entidade e teria dentro referencia para os diversos posts que obviamente são entidades. O total de posts seria justamente um comportamento dela, contando o número de posts associados.
Já a nuvem pode ser objeto valor ou simplesmente um serviço, não consigo ter uma boa base para decidir com tão poucas informações. Lembrando que um objeto valor pode conter dentro dele referencias a entidades!

Eu acho que Tag é um Value Object. Qual a diferença entre duas tags chamadas “java”? Nenhuma, até onde posso ver. Se um objeto é definido exclusivamente por seus atributos, ele é um Value Object e não uma Entidade. Mas posso estar errado.

x@ndy:

Uma análise bem superficial com base no que você valou me passa que a tag tem uma identidade única o que a caracteriza como uma entidade e teria dentro referencia para os diversos posts que obviamente são entidades. O total de posts seria justamente um comportamento dela, contando o número de posts associados.
Já a nuvem pode ser objeto valor ou simplesmente um serviço, não consigo ter uma boa base para decidir com tão poucas informações. Lembrando que um objeto valor pode conter dentro dele uma entidade!

Tag poderia ser uma entidade se ele precisar manter um historico da evolução de cada tag registrado no sistema, o que não me parece ser o caso.

Como um objeto valor poderia conter uma entidade e ainda assim permanecer imutavel?

Como eu disse a análise é superficial. Eu entendi dessa maneira, antes de implementar teria que análisar e modelar melhor.

Ops, temos um problema de conceito ai. O objeto valor é imutável mas seus atributos não!!! Exemplo: Se considerarmos uma entidade pessoa e que ela tenha um endereço como objeto valor. O objeto endereço é imutável e é somente dessa pessoa correto né! Porém essa pessoa pode se mudar, ou seja, os atributos logradouro, número, bairro, etc da classe endereço teriam que ter novos valores! O objeto endereço deixaria de ser imutável então?! Não!! A pessoa receberia apenas um novo endereço!

“OBJETOS VALOR podem até se referir a ENTIDADES. Por exemplo, se eu pedir a um serviço de mapas online uma rota panorâmica de São Fransisco a Los Angeles, ele poderia deduzir um objeto Rota Ligando Los Angeles a São Fransisco através da Pacific Coast Highway. Esse objeto Rota seria um VALOR embora os três objetos a que ele se refere (duas cidades e uma estrada) sejam ENTIDADES” Eric Evans, Domain-Drive Design, página 94

x@ndy:

Ops, temos um problema de conceito ai. O objeto valor é imutável mas seus atributos não!!! Exemplo: Se considerarmos uma entidade pessoa e que ela tenha um endereço como objeto valor. O objeto endereço é imutável e é somente dessa pessoa correto né! Porém essa pessoa pode se mudar, ou seja, os atributos logradouro, número, bairro, etc da classe endereço teriam que ter novos valores! O objeto endereço deixaria de ser imutável então?! Não!! A pessoa receberia apenas um novo endereço!

Não sei aonde quer chegar. Eu questionei objeto valor conter uma entidade, o seu exemplo é de uma entidade contendo um valor objeto.

O fato é, se um objeto é imutavel, ele pode conter no máximo um identificador, mas não pode conter a própria entidade, que é mutável.

x@ndy:

“OBJETOS VALOR podem até se referir a ENTIDADES. Por exemplo, se eu pedir a um serviço de mapas online uma rota panorâmica de São Fransisco a Los Angeles, ele poderia deduzir um objeto Rota Ligando Los Angeles a São Fransisco através da Pacific Coast Highway. Esse objeto Rota seria um VALOR embora os três objetos a que ele se refere (duas cidades e uma estrada) sejam ENTIDADES” Eric Evans, Domain-Drive Design, página 94

Acho que a primeira sentença diz tudo né?

Verbo

re.fe.rir

1. mencionar, citar, fazer alusão
   * ele se referiu a essa entidade como “uma nova força política”

Obviamente, o Xandy quis dizer “conter uma referência a uma Entidade” quando disse “conter uma Entidade”.

Sim!
No primeiro Post eu já coloquei isso
Uma análise bem superficial com base no que você valou me passa que a tag tem uma identidade única o que a caracteriza como uma entidade e teria dentro referencia para os diversos posts que obviamente são entidades. O total de posts seria justamente um comportamento dela, contando o número de posts associados.

mochuara:

x@ndy:

Ops, temos um problema de conceito ai. O objeto valor é imutável mas seus atributos não!!! Exemplo: Se considerarmos uma entidade pessoa e que ela tenha um endereço como objeto valor. O objeto endereço é imutável e é somente dessa pessoa correto né! Porém essa pessoa pode se mudar, ou seja, os atributos logradouro, número, bairro, etc da classe endereço teriam que ter novos valores! O objeto endereço deixaria de ser imutável então?! Não!! A pessoa receberia apenas um novo endereço!

Não sei aonde quer chegar. Eu questionei objeto valor conter uma entidade, o seu exemplo é de uma entidade contendo um valor objeto.

O fato é, se um objeto é imutavel, ele pode conter no máximo um identificador, mas não pode conter a própria entidade, que é mutável.

x@ndy:

“OBJETOS VALOR podem até se referir a ENTIDADES. Por exemplo, se eu pedir a um serviço de mapas online uma rota panorâmica de São Fransisco a Los Angeles, ele poderia deduzir um objeto Rota Ligando Los Angeles a São Fransisco através da Pacific Coast Highway. Esse objeto Rota seria um VALOR embora os três objetos a que ele se refere (duas cidades e uma estrada) sejam ENTIDADES” Eric Evans, Domain-Drive Design, página 94

Acho que a primeira sentença diz tudo né?

Corrigi o trecho! Onde disse conter eu queria dizer conter uma referencia. Realmente não havia ficado claro. Imaginei que você estava questinando a imutabilidade dos atributos ou comportamento de um objeto valor, que podem mudar!

Então ele quis dizer “Value objects podem conter uma Entidade” querendo na vedade dizer “Value Objects podem conter apenas value objects” e isso é obvio?

x@ndy:

mochuara:

x@ndy:

Ops, temos um problema de conceito ai. O objeto valor é imutável mas seus atributos não!!! Exemplo: Se considerarmos uma entidade pessoa e que ela tenha um endereço como objeto valor. O objeto endereço é imutável e é somente dessa pessoa correto né! Porém essa pessoa pode se mudar, ou seja, os atributos logradouro, número, bairro, etc da classe endereço teriam que ter novos valores! O objeto endereço deixaria de ser imutável então?! Não!! A pessoa receberia apenas um novo endereço!

Não sei aonde quer chegar. Eu questionei objeto valor conter uma entidade, o seu exemplo é de uma entidade contendo um valor objeto.

O fato é, se um objeto é imutavel, ele pode conter no máximo um identificador, mas não pode conter a própria entidade, que é mutável.

Corrigi o trecho! Onde disse conter eu queria dizer conter uma referencia. Realmente não havia ficado claro. Imaginei que você estava questinando a imutabilidade dos atributos ou comportamento de um objeto valor, que podem mudar!

O que vc entende por referencia em DDD?

adtve:

E ai pessoal, blz?

Bom, eu estou com uma dúvida… estou precisando desenvolver um site que tenha tag cloud, aquelas tags que são associadas a alguma coisa e quanto mais associações esse tag tiver a tag é exibida com mais destaque. Eu quero usar os conceitos de DDD pra esse site e minha dúvida é de como implementar essa funcionalidade. Pra mim uma tag é um V.O com uma descrição e sua quantidade, mais como eu faria pra persistir a sua quantidade e como eu faria pra recuperar as tags elas sendo V.Os? Eu sei que posso transformar esse V.O em uma entidade e esta td resolvido mais acho q nesse caso eu estaria indo contra o que é lógico que é tornar a tag um V.O.

Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!

1. A meu ver a Tag é uma ENTIDADE nesse caso porque ela é unica e precisa ter uma identidade além de necessitar ser persistida. Eu não posso ter Tags repetidas. Essa Tag teria referências aos diversos Posts, que também são entidades. A contagem do número de Posts não deveria ser um atributo da tag e sim um comportamento do objeto que calcula o total com base nos posts referenciados. Não faz muito sentido, “do meu ponto de vista”, a classe conter referências aos Posts e um contador para dizer quantos posts ela contém! É mais fácil calcular o número de referências!
2. A nuvem seria um OBJETO VALOR contendo diversas referencias as Tags. A nuvem seria única. Não faz sentido ser uma entidade! A não ser é claro, que você queira ter diversas nuvens com identidades separadas, ai tudo muda de figura!

Então ele quis dizer “Value objects podem conter uma Entidade” querendo na vedade dizer “Value Objects podem conter apenas value objects” e isso é obvio?
Não. Eu disse explicitamente que Objetos Valor podem conter referência a entidades!

Não entendi sua colocação! Você quer dizer que um OBJETO VALOR, só pode conter outros OBJETOS VALORES e nunca pode conter uma referência a uma entidade é isso?

mochuara:

x@ndy:

mochuara:

x@ndy:

Ops, temos um problema de conceito ai. O objeto valor é imutável mas seus atributos não!!! Exemplo: Se considerarmos uma entidade pessoa e que ela tenha um endereço como objeto valor. O objeto endereço é imutável e é somente dessa pessoa correto né! Porém essa pessoa pode se mudar, ou seja, os atributos logradouro, número, bairro, etc da classe endereço teriam que ter novos valores! O objeto endereço deixaria de ser imutável então?! Não!! A pessoa receberia apenas um novo endereço!

Não sei aonde quer chegar. Eu questionei objeto valor conter uma entidade, o seu exemplo é de uma entidade contendo um valor objeto.

O fato é, se um objeto é imutavel, ele pode conter no máximo um identificador, mas não pode conter a própria entidade, que é mutável.

Corrigi o trecho! Onde disse conter eu queria dizer conter uma referencia. Realmente não havia ficado claro. Imaginei que você estava questinando a imutabilidade dos atributos ou comportamento de um objeto valor, que podem mudar!

O que vc entende por referencia em DDD?

x@ndy:

adtve:

E ai pessoal, blz?

Bom, eu estou com uma dúvida… estou precisando desenvolver um site que tenha tag cloud, aquelas tags que são associadas a alguma coisa e quanto mais associações esse tag tiver a tag é exibida com mais destaque. Eu quero usar os conceitos de DDD pra esse site e minha dúvida é de como implementar essa funcionalidade. Pra mim uma tag é um V.O com uma descrição e sua quantidade, mais como eu faria pra persistir a sua quantidade e como eu faria pra recuperar as tags elas sendo V.Os? Eu sei que posso transformar esse V.O em uma entidade e esta td resolvido mais acho q nesse caso eu estaria indo contra o que é lógico que é tornar a tag um V.O.

Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!

1. A meu ver a Tag é uma ENTIDADE nesse caso porque ela é unica e precisa ter uma identidade além de necessitar ser persistida. Eu não posso ter Tags repetidas. Essa Tag teria referências aos diversos Posts, que também são entidades. A contagem do número de Posts não deveria ser um atributo da tag e sim um comportamento do objeto que calcula o total com base nos posts referenciados. Não faz muito sentido, “do meu ponto de vista”, a classe conter referências aos Posts e um contador para dizer quantos posts ela contém! É mais fácil calcular o número de referências!
2. A nuvem seria um OBJETO VALOR contendo diversas referencias as Tags. A nuvem seria única. Não faz sentido ser uma entidade! A não ser é claro, que você queira ter diversas nuvens com identidades separadas, ai tudo muda de figura!

Não creio que ele tenha um objeto nuvem no dominio (a menos que ele esteja modelando o ceu! rs).

x@ndy:

Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!

1. A meu ver a Tag é uma ENTIDADE nesse caso porque ela é unica e precisa ter uma identidade além de necessitar ser persistida. Eu não posso ter Tags repetidas. Essa Tag teria referências aos diversos Posts, que também são entidades. A contagem do número de Posts não deveria ser um atributo da tag e sim um comportamento do objeto que calcula o total com base nos posts referenciados. Não faz muito sentido, “do meu ponto de vista”, a classe conter referências aos Posts e um contador para dizer quantos posts ela contém! É mais fácil calcular o número de referências!
2. A nuvem seria um OBJETO VALOR contendo diversas referencias as Tags. A nuvem seria única. Não faz sentido ser uma entidade! A não ser é claro, que você queira ter diversas nuvens com identidades separadas, ai tudo muda de figura!

Boa, acho que você pegou o ponto.

x@ndy:

A mesma coisa que significa em Java. É contér uma referência a um Objeto. Esse objeto pode mudar indepente de quantas referências ele tem.
Vou pegar o exemplo do Evans. A Rota é um OBJETO VALOR que contém referência a duas cidades que são ENTIDADES. As Cidades podem mudar seu comportamento independemente da Rota, digamos que um dos comportamentos dessa classe cidade seja o número de habitantes nacidos nela. Isso mudaria a todo o minuto!

Deve ser por isso que esta fazendo confusão. Referencias em DDD não tem nada a ver com referencias em linguagens OO.

E quando diz que um objeto valor pode conter uma referencia para uma entidade está equivocado.

mochuara:

x@ndy:

adtve:

E ai pessoal, blz?

Bom, eu estou com uma dúvida… estou precisando desenvolver um site que tenha tag cloud, aquelas tags que são associadas a alguma coisa e quanto mais associações esse tag tiver a tag é exibida com mais destaque. Eu quero usar os conceitos de DDD pra esse site e minha dúvida é de como implementar essa funcionalidade. Pra mim uma tag é um V.O com uma descrição e sua quantidade, mais como eu faria pra persistir a sua quantidade e como eu faria pra recuperar as tags elas sendo V.Os? Eu sei que posso transformar esse V.O em uma entidade e esta td resolvido mais acho q nesse caso eu estaria indo contra o que é lógico que é tornar a tag um V.O.

Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!

1. A meu ver a Tag é uma ENTIDADE nesse caso porque ela é unica e precisa ter uma identidade além de necessitar ser persistida. Eu não posso ter Tags repetidas. Essa Tag teria referências aos diversos Posts, que também são entidades. A contagem do número de Posts não deveria ser um atributo da tag e sim um comportamento do objeto que calcula o total com base nos posts referenciados. Não faz muito sentido, “do meu ponto de vista”, a classe conter referências aos Posts e um contador para dizer quantos posts ela contém! É mais fácil calcular o número de referências!
2. A nuvem seria um OBJETO VALOR contendo diversas referencias as Tags. A nuvem seria única. Não faz sentido ser uma entidade! A não ser é claro, que você queira ter diversas nuvens com identidades separadas, ai tudo muda de figura!

Não creio que ele tenha um objeto nuvem no dominio (a menos que ele esteja modelando o ceu! rs).

Na verdade esse é um ponto interessante também. No DDD devemos usar a linguagem onipresente e modelar o dominio da mesma “forma que falamos” ou seja, o dominio deve representar o negócio da melhor maneira possível. Então como você chamaria a Nuvem neste caso? E não me venha com CloudTags ou NuvemDeTags, pois pode ser também e é meio obvio e para uma simples e rápida explicação não vejo tanto mérito assim nessas duas variações.

mochuara:

x@ndy:

A mesma coisa que significa em Java. É contér uma referência a um Objeto. Esse objeto pode mudar indepente de quantas referências ele tem.
Vou pegar o exemplo do Evans. A Rota é um OBJETO VALOR que contém referência a duas cidades que são ENTIDADES. As Cidades podem mudar seu comportamento independemente da Rota, digamos que um dos comportamentos dessa classe cidade seja o número de habitantes nacidos nela. Isso mudaria a todo o minuto!

Deve ser por isso que esta fazendo confusão. Referencias em DDD não tem nada a ver com referencias em linguagens OO.

E quando diz que um objeto valor pode conter uma referencia para uma entidade está equivocado.

Bom então, posso estar errado! Não sou dono da verdade eu entendi assim!
Me diga então como seria o exemplo da Rota na qual ele diz que tem referência a três entidades? Como isso funcionaría!

No mesmo livro citado explica isso. A idéia é usar value-objects como as referencias, e usa-las no repositório como id para acessar entidades.

Ops, não entendi nada do que disse.
"A idéia é usar value-objects como as referencias"
Ahnn???
e e usa-las no repositório como id para acessar entidades.
Você quer dizer que Os OBJETOS VALOR devem ser usados como o identificador da entidade? E isso?

Sim. Referencias em domain model são resolvidas pelo repositorio.

Pera ai vamos me confirme se eu entendi o que você quer dizer!

1. Uma ENTIDADE deve conter OBJETOS VALOR que são utilizados como identificadores dos objetos, portanto um OBJETO VALOR não pode conter uma ENTIDADE em DDD.
2. As referencias são resolvidas pelo REPOSITÓRIO!
   É isso?

x@ndy:

Pera ai vamos me confirme se eu entendi o que você quer dizer!

1. Uma ENTIDADE deve conter OBJETOS VALOR que são utilizados como identificadores dos objetos, portanto um OBJETO VALOR não pode conter uma ENTIDADE em DDD.
2. As referencias são resolvidas pelo REPOSITÓRIO!
   É isso?

Acho que vc esta fazendo parecer mais complicado do que na verdade é.

O fato é que Eric Evans não falou de referencia como endereço do objeto na memória, mas um identificador (uma string ou integer) que identifica unicamente a entidade no sistema e que vai ser acessada por meio do repositorio. O objeto valor não contem a entidade, apenas este identificador.

http://dddsample.sourceforge.net/characterization.html#Value_Objects
O projeto é do Eric Evans, ok?

http://dddsample.sourceforge.net/xref/se/citerus/dddsample/domain/model/cargo/Leg.html

Leg é um VO (implementa ValueObject) e referencia (“contém um private member do tipo de”) 2 Locations (implementa Entity) e 1 Voyage (implementa Entity).

mochuara:

x@ndy:

Pera ai vamos me confirme se eu entendi o que você quer dizer!

1. Uma ENTIDADE deve conter OBJETOS VALOR que são utilizados como identificadores dos objetos, portanto um OBJETO VALOR não pode conter uma ENTIDADE em DDD.
2. As referencias são resolvidas pelo REPOSITÓRIO!
   É isso?

Acho que vc esta fazendo parecer mais complicado do que na verdade é.

O fato é que Eric Evans não falou de referencia como endereço do objeto na memória, mas um identificador (uma string ou integer) que identifica unicamente a entidade no sistema e que vai ser acessada por meio do repositorio. O objeto valor não contem a entidade, apenas este identificador.

Na verdade eu vejo que você está complicando e não eu. O que você está falando é que a referência está ligada a IDENTIDADE de um objeto. Bem vamos definir tudo primeiro (Conforme o livro do Evans) para evitar mais confusões:

ENTIDADE: Objeto fundamental definido não por seus atributos, mas por uma cadeia de continuidade e identidade!
OBJETO VALOR:: Objeto que descreve alguma característica ou atributo, mas não traz consigo nenhum conceito de identidade!
REPOSITÓRIO: Mecanismo para encapsular o armazenamento, recuperação e comportamento de busca que imita uma coleção de objetos!
IDENTIDADE: No seu glossário ele não da nenhuma definição simples de identidade, mas na página 89 ele diz: “Cada ENTIDADE deve ter uma forma operacional de estabeler sua identidade com outro objeto - distinguível até mesmo a partir de outro objeto com os mesmos atributo descritivos. Deve-se garantir que um atributo de identificação seja único dentro do sistema, independente de como esse sistema seja definido - mesmo quando distribuído, e até mesmo quando os objetos são arquivados”

Ele não diz em parte alguma do livro, que uma referência está ligada diretamente a identidade de um objeto. Eu entendo que, o que ele quer dizer com referência, é o mesmo que associação. Quando um objeto contém uma referencia para outro objeto é o mesmo que dizer que eles estão associados! E assim como eu posso ter entidades associadas eu posso ter uma associação entre objetos valor e sua entidades, o problema é sempre sentido da associação. Como se dá associação é indiferente como ele mesmo diz na página 78:
“Um modelo que mostra uma associação entre um cliente e um representante de vendas corresponde a duas coisas. Por um lado, ele abstrai uma relação que os desenvolvedores julgavam importante entre duas pessoas reais. Por outro lado, ele corresponde a um ponteiro de objetos entre dois objetos java ou um encapsulamento de uma consulta ao banco de dados ou alguma implementação comparável”

Seria uma falha no trabalho do E. Evans. Objetos imutáveis não são de fato imutáveis?

Antes defina o que eu você entende por Objeto Imutavel?

Se uma entidade varia com o tempo e o objecto valor possui uma associacao direta com essa entidade o próprio objeto valor deixa de ser imutável.

Bom, isto se considerarmos que uma associação entre objetos é uma composição.

esmiralha:

http://dddsample.sourceforge.net/characterization.html#Value_Objects
O projeto é do Eric Evans, ok?

http://dddsample.sourceforge.net/xref/se/citerus/dddsample/domain/model/cargo/Leg.html

Leg é um VO (implementa ValueObject) e referencia (“contém um private member do tipo de”) 2 Locations (implementa Entity) e 1 Voyage (implementa Entity).

Repare que Location e Voyage são imutáveis, o que não representa um perigo neste exemplo de livro. Mas um projeto real entidades costumam ter setters e addIsso addAquilo, ou seja, metodos que atuam no objeto fazendo com que ele mude de estado. Neste caso é melhor usar o identificador do Entidade e não referenciar diretamente, sob o risco de introduzir o conceito de Leg incosistente no seu modelo.

mochuara:

Se uma entidade varia com o tempo e o objecto valor possui uma associacao direta com essa entidade o próprio objeto valor deixa de ser imutável.

Bom, isto se considerarmos que uma associação entre objetos é uma composição.

Bom vamos lá, vou tentar explicar o que eu entendi por imutavel no livro dele:

Uma ENTIDADE é composta por uma série de OBJETOS VALOR, esses podem ser Strings, Inteiros ou Até um outro objeto do Dominio, como o endereço!
Um objeto pessoa pode mudar com o passar dos anos, a idade dela se altera, seu endereço e até seu nome podem mudar, mas ela deixa de ser a mesma pessoa? Não porque ela continua tendo a mesma IDENTIDADE. Mas ela é Mutavel (Acho que a palavra mutante seria melhor, pois mesmo mudando ainda continua sendo o mesmo objeto!)
Ai o conceito de que um OBJETO VALOR é imutável da maneira que você acha que é já foi pro saco pois para uma ENTIDADE variar se seus OBJETOS VALOR serão diferentes com o passar do tempo!

O que ele quer dizer com imutável então! A meu ver que o objeto valor é único para uma Entidade. Ele não varia com o tempo nos moldes da ENTIDADE.
Vamos considerar um objeto valor Endereço! Duas pessoas podem residir juntas “tendo assim o mesmo endereço”. Só que se elas possuim o mesmo endereço, ou seja o compartilham o objeto Endereço, e uma delas se mudar o endereço da outra também mudaria! Então o objeto Endereço tem que ser Imutável na relação entre duas pessoas ou seja ele não pode ser compartilhado. Logo em uma implementação ele seria único para cada pessoa! Eu possoa até passar uma cópia do endereço para outra pessoa, mas não uma referência para ele!

Uma entidde é mutavel, por que, com o passar dos anos, em um sistema de cobrança por exemplo, necessito saber o endereço novo da pessoa. Ou seja no meu objeto Cobrança vou ter uma referencia para entidade pessoa criando assim uma associação, sendo que a entidade pessoa poderá mudar com o tempo e minha classe Cobrança necessita saber disso para enviar uma Conta!

O OBJETO VALOR não pode mudar assim. Se o endereço ou nome de uma pessoa mudar ele não pode alterar o de outro objeto Pessoa. Ele tem que ser imutável então.

Fui claro?

Porque foi pro saco?

Se a pessoa tem 20 e completa 21 anos, a Entidade foi modificada, mas os valores objetos continuam imutáveis. 20 continua sendo Integer(20) e 21 continua sendo Integer(21).

x@ndy:

O que ele quer dizer com imutável então! A meu ver que o objeto valor é único para uma Entidade. Ele não varia com o tempo nos moldes da ENTIDADE.
Vamos considerar um objeto valor Endereço! Duas pessoas podem residir juntas “tendo assim o mesmo endereço”. Só que se elas possuim o mesmo endereço, ou seja o compartilham o objeto Endereço, e uma delas se mudar o endereço da outra também mudaria! Então o objeto Endereço tem que ser Imutável na relação entre duas pessoas ou seja ele não pode ser compartilhado. Logo em uma implementação ele seria único para cada pessoa! Eu possoa até passar uma cópia do endereço para outra pessoa, mas não uma referência para ele!

Uma entidde é mutavel, por que, com o passar dos anos, em um sistema de cobrança por exemplo, necessito saber o endereço novo da pessoa. Ou seja no meu objeto Cobrança vou ter uma referencia para entidade pessoa criando assim uma associação, sendo que a entidade pessoa poderá mudar com o tempo e minha classe Cobrança necessita saber disso para enviar uma Conta!

O OBJETO VALOR não pode mudar assim. Se o endereço ou nome de uma pessoa mudar ele não pode alterar o de outro objeto Pessoa. Ele tem que ser imutável então.

Fui claro?

Eu ficaria surpreso se descobrisse que era essa visão de imutabilidade do Eric Evans quando escreveu o livro.

mochuara:

Porque foi pro saco?

Se a pessoa tem 20 e completa 21 anos, a Entidade foi modificada, mas os valores objetos continuam imutáveis. 20 continua sendo Integer(20) e 21 continua sendo Integer(21).

Cara, eu não disse que os valores deixaram de existir eu disse que eles mudaram por que foram substiuidos. Eu substitui Integer(20) por Integer(21) Ok!
O meu objeto valor Idade continua sendo imutável! Ele foi substiuido por outro valor objeto valor! O que eu quero dizer é que OBJETOS VALOR não tem identidade, eles são sempre substituídos e nunca compartilhados é por isso que são Imutáveis.

mochuara:

x@ndy:

O que ele quer dizer com imutável então! A meu ver que o objeto valor é único para uma Entidade. Ele não varia com o tempo nos moldes da ENTIDADE.
Vamos considerar um objeto valor Endereço! Duas pessoas podem residir juntas “tendo assim o mesmo endereço”. Só que se elas possuim o mesmo endereço, ou seja o compartilham o objeto Endereço, e uma delas se mudar o endereço da outra também mudaria! Então o objeto Endereço tem que ser Imutável na relação entre duas pessoas ou seja ele não pode ser compartilhado. Logo em uma implementação ele seria único para cada pessoa! Eu possoa até passar uma cópia do endereço para outra pessoa, mas não uma referência para ele!

Uma entidde é mutavel, por que, com o passar dos anos, em um sistema de cobrança por exemplo, necessito saber o endereço novo da pessoa. Ou seja no meu objeto Cobrança vou ter uma referencia para entidade pessoa criando assim uma associação, sendo que a entidade pessoa poderá mudar com o tempo e minha classe Cobrança necessita saber disso para enviar uma Conta!

O OBJETO VALOR não pode mudar assim. Se o endereço ou nome de uma pessoa mudar ele não pode alterar o de outro objeto Pessoa. Ele tem que ser imutável então.

Fui claro?

Eu ficaria surpreso se descobrisse que era essa visão de imutabilidade do Eric Evans quando escreveu o livro.

Bom eu estou tentando explicar da melhor maneira. Pode não ser o ideal, ou derrepente não estou conseguindo passar direito o que eu entendi, só que o engraçado é que até agora você criticou meu ponto de vista mas não deu explicação alguma! Então por que tu não explica para mim o que imutabilidade, como eu te perguntei antes? E por que eu não posso usar a palavra Nuvem para o modelo que ele citou?

Deixa eu ver se entendi, o objeto valor que tem uma entidade continua sendo imutavel porque ele não depende dos valores da entidade, apenas na sua identidade.

mochuara:

esmiralha:

http://dddsample.sourceforge.net/characterization.html#Value_Objects
O projeto é do Eric Evans, ok?

http://dddsample.sourceforge.net/xref/se/citerus/dddsample/domain/model/cargo/Leg.html

Leg é um VO (implementa ValueObject) e referencia (“contém um private member do tipo de”) 2 Locations (implementa Entity) e 1 Voyage (implementa Entity).

Repare que Location e Voyage são imutáveis, o que não representa um perigo neste exemplo de livro.

Repare que Cargo é mutável, é referenciado por HandlingEvent, que por sua vez é referenciado por Delivery (VO).

Haanh?
Eu acho que você quer é confusão por que não explica nada e ainda tenta confundir mais!

Provavelmente vc está certo e há falha não está no DDD, e sim nas linguagens OO.

People accustomed to OO conceive of their programs as mutating the values of objects. They understand the true notion of a value, say, 42, as something that would never change, but usually don’t extend that notion of value to their object’s state. That is a failure of their programming language. These languages use the same constructs for modeling values as they do for identities, objects, and default to mutability, causing all but the most disciplined programmers to create many more identities than they should, creating identities out of things that should be values etc.

http://clojure.org/state

Ou talvez a falha esteja em seu código genético.

Cara não da mais confiança que deu para ver que esse é troll de internet, eu que fui trouxa e pensava que estava numa discussão séria!

Pelo visto esgotou o estoque de citacoes?

e o troll ataca novamente…ele não veio para esclarecer e sim para confundir…

Seu objeto imutavel é na verdade mutável, apenas haja de acordo.

Seu objeto imutavel é na verdade mutável, apenas haja de acordo.

Então porque o presente Troll não explica para nós simples mortais qual o significado de imutabilidade que o Evans fala? Explique também o que ele quis dizer com um OBJETO VALOR com referências a ENTIDADES? Não diz ou porque não sabe ou porque veio para confundir não para esclarecer.
Pessoal já notou que até agora o grande Troll mochuara não explicou nada, só falou que os outros estão errados? Qual a finalidade disso afinal?

Seu objeto imutavel é na verdade mutável, apenas haja de acordo.

Então porque o presente Troll não explica para nós simples mortais qual o significado de imutabilidade que o Evans fala? Explique também o que ele quis dizer com um OBJETO VALOR com referências a ENTIDADES? Não diz ou porque não sabe ou porque veio para confundir não para esclarecer.
Pessoal já notou que até agora o grande Troll mochuara não explicou nada, só falou que os outros estão errados? Qual a finalidade disso afinal?

Este é um fórum gratuito, ninguém te deve nada, nem mesmo explicações.

Sobre o tema em questão, se possui uma definição propria de imutabilidade diferente da oficial que é não permitir um objeto ser alterado por nenhuma thread então nos diga.

class A {
 private String nome;

 public A(String nome) {this.nome = nome;}
 public String getNome() { return nome; }
}

A objA = new A("imutavel");

class B {
 private int codigo;
 private String nome;

 public B(int codigo, String nome) {this.codigo = codigo; this.nome = nome;}
 public int getCodigo() { return codigo; }
 public String getNome() { return nome; }
 public void setNome(String nome) { this.nome = nome; }
}

B objB = new B(1, "imutavel");
objB.setNome("mudou");

class C {
 private String nome;
 private B b;

 public C(String nome, B b) {this.nome = nome; this.b = b;}
 public String getNome() { return nome; }
 public B getB() {return b; }
}

B objB = new B(1, "mutavel");
C objC = new C("imutavel?", objB);

Porém se B tiver o hashCode e equals, definidos usando-se apenas o codigo (que não é alterado) ele seria imutável ou mutável?

mochuara:

Este é um fórum gratuito, ninguém te deve nada, nem mesmo explicações.

Sobre o tema em questão, se possui uma definição propria de imutabilidade diferente da oficial que é não permitir um objeto ser alterado por nenhuma thread então nos diga.

O que disse é que um Objeto Valor pode conter referências a Entidades, não disse que esse objeto valor pode ser alterado, de maneira alguma!
Se pegarmos o proprio exemplo do Evans da Rota como um Objeto Valor e as Cidades como Entidades. Se os atributos das entidades mudarem a rota vai continuar sendo a mesma não vai? Digamos que rodovia tenha 3 pistas e passe a ter 6 a Rota irá mudar? Não né! Agora uma coisa diferente é eu permitir que, se eu “compartilhar” uma referencia desse objeto Rota com outro objeto, que esse objeto substitua alguma das instancias da rota, digamos, troque a cidade de São Francisco por Chigago, isso quebraria alguma invariante do meu objeto Rota tornando o inválido, por isso o Objeto Rota tem que ser Imutável.
Um Objeto Valor pode conter Entidades porque mesmo que os atributos das entidades variem, elas continuam sendo sempre a mesma entidade pois sua identidade não muda. Uma rodovia não passa a ser uma nova rodovia por que deixou de ter 3 pistas para ter 6, a identidade dela continua sendo a mesma! Assim eu não quebro Imutabilidade.

Já com Entidades com Objetos Valor é diferente. Digamos que eu tenha uma Entidade Pessoa e essa possui um Objeto Valor Endereco. Se eu tenho dois Objetos Pessoas que residem juntos eu posso fazer com que elas compartilhem a mesma referência para um Objeto Endereco. Só que se uma delas se mudar e alterar os atributos do objeto Endereco vai acabar modificando o endereço da outra pessoa também! Então tenho que tornar esse objeto Endereco Imutável, não permitindo que seus atributos sejam alterados quando o objeto for compartilhado. Então quem se mudasse teria que criar uma nova instancia do objeto Endereco para si!

Edufa:

Não posso alterar diretamente C, mas alterando B, C é alterado.
um objeto para ser considerado imutável, tem de garantir que todos os objetos que ele referencia tb são?

Porém se B tiver o hashCode e equals, definidos usando-se apenas o codigo (que não é alterado) ele seria imutável ou mutável?

Se eu compartilhar C e algum objeto alterar o objeto B e esse quebrar uma invariante de C (o nome e código são importantes para C) então eu não poderia permitir que B fosse alterado! Então eu teria que compartilhar uma cópia de B (ou torna-lo imutável):

...
public B getB() {return new B(b.codigo, codigo.nome); }

Agora, se eu puder alterar B de forma que isso não quebre nenhuma invariante de C, ou seja se o nome puder ser alterado pois o que importa para C é somente o código então B não necessita ser imutável!

É por isso que um Objeto Valor pode conter referências para Entidades, mesmo que os atributos da entidade mudem ela continua sendo a mesma entidade por que sua identidade não muda!
Claro, e isso é óbvio, que se algum atributo da entidade for importante para o Objeto Valor de modo que, se for alterado, possa quebrar uma de suas invariantes, então não posso utilizar uma referência e terei que ter uma cópia dessa entidade. Também não posso permitir que essa cópia seja alterada se eu compartilhar uma referência do meu Objeto Valor!
Não sei se fui claro! Conseguiu entender?

Xandy,

class Rota {

private Cidade origem;
private Cidade destino;

public Rota(final Cidade origem, final Cidade destino) {
  this.origem = origem;
  this.destino = destino;
}

public Distancia distancia() {
  return origem.distanciaAte(destino);
}
}

Se o método distanciaAte depender de algum estado mutável de Cidade, é possível que ele retorne valores diferentes ao longo do tempo, porque Rota armazena uma referência para Cidade.

É importante garantir que seu objeto imutável não exponha um comportamento que depende de um estado mutável?

Se Rota armazenasse uma cópia de Cidade, isso não aconteceria.

esmiralha:

Xandy,

class Rota {

private Cidade origem;
private Cidade destino;

public Rota(final origem, final destino) {
  this.origem = origem;
  this.destino = destino;
}

public Distancia distancia() {
  return origem.distanciaAte(destino);
}
}

Se o método distanciaAte depender de algum estado mutável de Cidade, é possível que ele retorne valores diferentes ao longo do tempo, porque Rota armazena uma referência para Cidade.

É importante garantir que seu objeto imutável não exponha um comportamento que depende de um estado mutável?

Se Rota armazenasse uma cópia de Cidade, isso não aconteceria.

Sim. No tópico acima, que respondi para o Edufa, no último paragrafo eu falei sobre isso!

"Claro, e isso é óbvio, que se algum atributo da entidade for importante para o Objeto Valor de modo que, se for alterado, possa quebrar uma de suas invariantes, então não posso utilizar uma referência e terei que ter uma cópia dessa entidade. Também não posso permitir que essa cópia seja alterada se eu compartilhar uma referência do meu Objeto Valor! "

No caso estou considerando que a Rota não dependa de nenhum dos atributos das Entidades a não ser da identidade da propria entidade! :wink:

Sim. E além disso, se é importante a linguagem garantir isso, ou o programador. É claro que o programador é responsável pelo design mas acredito que a linguagem tem que tornar a tarefa mais fácil possível, e clojure é um passo nessa direção sendo a unica (somada com linguagens mais puras e academicas, como haskell) com um modelo voltado para separação entre entidades x objetos valor. Se não fica que nem Java… Onde ninguém sabe o que é um objeto imutável! :roll:

esmiralha:

Se Rota armazenasse uma cópia de Cidade, isso não aconteceria.

Poderia explicar porque? se o estado continua mutável…

mochuara:

esmiralha:

Se Rota armazenasse uma cópia de Cidade, isso não aconteceria.

Poderia explicar porque?

Porque sendo uma cópia, o objeto mutável não pode ser alterado exceto de dentro da própria classe Rota e você pode garantir que isso não aconteça.

Isso não é verdade, como bem observou o esmiralha.

Isso não contradiz o quote de cima e vai de encontro ao que estou dizendo, usar o código como referencia e não o proprio objeto?

mochuara:

x@ndy:

Um Objeto Valor pode conter Entidades porque mesmo que os atributos das entidades variem, elas continuam sendo sempre a mesma entidade pois sua identidade não muda. Uma rodovia não passa a ser uma nova rodovia por que deixou de ter 3 pistas para ter 6, a identidade dela continua sendo a mesma! Assim eu não quebro Imutabilidade.

Isso não é verdade, como bem observou o esmiralha.

O que o colega esmiralha colocou é uma coisa que eu já tinha falado com edufa e vou colocar aqui de novo:
“Claro, e isso é óbvio, que se algum atributo da entidade for importante para o Objeto Valor de modo que, se for alterado, possa quebrar uma de suas invariantes, então não posso utilizar uma referência e terei que ter uma cópia dessa entidade. Também não posso permitir que essa cópia seja alterada se eu compartilhar uma referência do meu Objeto Valor!”

Não posso afirmar que o colega esmiralha tenha concordo, mas creio que sim, já que não questionou minha colocação.

mochuara:

x@ndy:

Isso não contradiz o quote de cima e vai de encontro ao que estou dizendo, usar o código como referencia e não o proprio objeto?

Dando continuidade, me corrija se eu estiver enganado, mas o primeiro problema que eu vejo com seu ponto de vista é que você acredita que um OBJETO VALOR tem que ser obrigatoriamente imutável, o que está errado! O objeto valor tem que ser imutável apenas se for compartilhada uma referencia sua com outro objeto! Se eu não quiser, ou não puder torná-lo imutável e desejar compartilha-lo, posso fazer isso mediante uma cópia do mesmo! E se esse OBJETO VALOR não for compartilhado não é necessário sequer torná-lo imutável (não que isso não seja uma boa prática)

A segundo problema que vejo também é com o conceito de identidade e associação de objetos! Pelo que entendi até agora e com base na sua primeira colocação, no seu ponto de vista, o OBJETO VALOR é mutável quando possui uma referência para uma ENTIDADE pois os atributos desta podem mudar independentemente do OBJETO VALOR.
Com certeza os atributos da ENTIDADE podem mudar, mas isso não quer dizer que um OBJETO VALOR seja mutavel por causa disso. Se as invariantes do objeto valor dependerem apenas da identidade de uma ENTIDADE então ele pode ter uma referencia para a ENTIDADE sim, já que identidade da ENTIDADE nunca muda. Se eu necessitar compartilhar esse objeto valor, posso torna-lo imutável também, pois o que tenho que garantir é que nenhuma das suas invariantes seja quebrada e se as invariantes dependem apenas da identidade da minha ENTIDADE então o que devo fazer é não permitir que seja atribuído ao OBJETO VALOR uma referencia para uma outra ENTIDADE.

O que vejo é uma grande confusão com relação as invariantes de um objeto. Como disse antes, não é por uma rodovia recebe mais pistas mais que ela deixa de ser a mesma rodovia, muito menos uma rota vai ser alterada se essa rodovia receber mais pistas. Agora se a rota depende de algum atributo dessa rodovia, digamos de um acesso, então não devemos permitir que essa rodovia mude, pois se mudar vai quebrar uma invariante do meu objeto rota tornando o mesmo inválido. Como a rodovia é uma ENTIDADE para compartilha-la devemos então fornecer para a rota uma copia do objeto rodovia e não devemos permitir que os atributos dessa cópia sejam alterados.

Agora o que não entendo mesmo, é que você teima que estou errado mas não diz por que! Me diga aonde estou errando e com base no que?

Sim, vc esta enganado. Eu não disse que objetos valor devem ser imutáveis, eu disse que para eles serem compartilhados, precisam ser imutáveis.

Por outro lado, para atingir o mesmo objetivo, vc tem que usar um monte de regras como “se o atributo X do objeto Y for importante para o objeto Z então faça isso”, que todo mundo sabe, não escala para um projeto real. Como vc comunica esses pecualiridades com os outros membros da equipe? Vcs não deveriam estar conversando sobre o dominio usando a linguagem do negócio ao inves de estarem criando regrinhas de como copiar objetos?

É claro que Rota depende de atributos da Rodovia que ela contem, senão não faria sentido ela ter uma referencia para rodovia em primeiro lugar. O que não entendo é o seguinte, porque vc acha melhor fazer todo esse malabarismo de copiar objetos, impedir que a entidade seja alterada(!), se vc pode simplesmente possuir o id dessa Rodovia e o cliente da Rota (um service por exemplo) usar o Repositório para acessar a Rodovia quando ele achar melhor?

Resumindo, porque complicar?

Eu prefiro comunicar aos desenvolvedores uma heurística simples para garantir que um objeto seja imutável, do que dizer para eles que um VO não pode referenciar diretamente uma Entidade e ter que mudar o domínio para atender a uma regra.

Se uma Rota começa em uma Cidade e termina em outra Cidade, que seja. Não vou referenciar PKs ao invés da própria Entidade, nem criar uma Entidade se Rota é um VO.

mochuara:

É claro que Rota depende de atributos da Rodovia que ela contem, senão não faria sentido ela ter uma referencia para rodovia em primeiro lugar. O que não entendo é o seguinte, porque vc acha melhor fazer todo esse malabarismo de copiar objetos, impedir que a entidade seja alterada(!), se vc pode simplesmente possuir o id dessa Rodovia e o cliente da Rota (um service por exemplo) usar o Repositório para acessar a Rodovia quando ele achar melhor?

Resumindo, porque complicar?

Não tem malabarismo.

public class Rota {
  private final Cidade origem;
  private final Cidade destino;
  
  public static Rota criarRota(final Cidade origem, final Cidade destino) {
     return new Rota(origem, destino);
  }

  private Rota(final Cidade origem, final Cidade destino) {
    this.origem = Cidade.criarCidade(origem);
    this.destino = Cidade.criarCidade(destino);
  }

}

Que grande malabarismo é esse??? Prover um método fábrica estático que receba um objeto da própria classe? Muito barulho por nada...

esmiralha:

Eu prefiro comunicar aos desenvolvedores uma heurística simples para garantir que um objeto seja imutável, do que dizer para eles que um VO não pode referenciar diretamente uma Entidade e ter que mudar o domínio para atender a uma regra.

Se uma Rota começa em uma Cidade e termina em outra Cidade, que seja. Não vou referenciar PKs ao invés da própria Entidade, nem criar uma Entidade se Rota é um VO.

E que heuristica simples seria essa? Se for aquela de copiar objetos sinto lhe dizer, mas não funciona, além de não ser nada simples (como se diferencia objetos copiados de não copiados?).

Seu exemplo que não mostra nada, que Rota mais sem graça. :lol:

Se algumas das Cidades forem alteradas sem Rota saber não vai acontecer nada, porque Rota não faz nada com as Cidades, o que vc quer provar com esse exemplo?

Bom não li isso que você disse em nenhum lugar, mas mesmo assim me desculpe então.

Bom, agora estamos tratando de outra questão pelo jeito, pois primeiro você disse que não era possivel ter em um Objeto Valor uma Entidade, agora você diz que não é viável para o projeto! Então vamos lá:

1º) A forma como as classes se relacionam são guiadas pelo domino e não por mim, ele me impõem as regras e não o contrário!
2°) Não sou eu que cria regras para “copiar” objetos isso depende justamente do dominio da aplicação e o próprio Evans fala sobre isso em seu livro!

Como você sabe? No meu dominio ela pode não depender! Já tive vários casos de Objetos Valor com Entidades que não dependiam de nenhum dos atributos das Entidades!
Isso é uma conclusão absurda! Não é por que você nunca utilizou algo assim que pode tirar esse tipo de conclusão.

mochuara:

O que não entendo é o seguinte, porque vc acha melhor fazer todo esse malabarismo de copiar objetos, impedir que a entidade seja alterada(!), se vc pode simplesmente possuir o id dessa Rodovia e o cliente da Rota (um service por exemplo) usar o Repositório para acessar a Rodovia quando ele achar melhor?

Resumindo, porque complicar?

Eu não estou criando malabarismo nenhum, você que não entendeu a situação!

Se a Rota depende de qualquer atributo da rodovia de que me adianta ter um id desta ou uma referencia direta a classe? Qualquer um pode alterar em qualquer momento a rodovia o que quebraria as invariantes da Rota! A cópia da Entidade se faz necessário justamente para não quebrar as invariantes do Objeto Valor!

Se a rota não depende dos atributos da rodovia, a forma como é feito a referencia é irrelevante, seja através do id da rodovia ou uma referencia direta entre os objetos.

Bom não li isso que você disse em nenhum lugar, mas mesmo assim me desculpe então.

Está implicito, ser compartilhado livremente é uma das grandes maravilhas dos objetos valor.

x@ndy:

Bom, agora estamos tratando de outra questão pelo jeito, pois primeiro você disse que não era possivel ter em um Objeto Valor uma Entidade, agora você diz que não é viável para o projeto! Então vamos lá:

Ah novamente, me desculpa, eu achei que estavamos falando de DDD no mundo real, e não em exemplos de livro.

x@ndy:

1º) A forma como as classes se relacionam são guiadas pelo domino e não por mim, ele me impõem as regras e não o contrário!
2°) Não sou eu que cria regras para “copiar” objetos isso depende justamente do dominio da aplicação e o próprio Evans fala sobre isso em seu livro!

Se seu objeto é mutavel (e entidades são mutáveis) elas podem ser alteradas por outras threads. Se seu objeto valor depende de atributos da entidade (e certamente dependerá) então vc pode ter bugs no seu sistema, a não ser que use locks!

Imagine que a Rota fornece sua distancia. Ela depende do atributo marcoZero de cada cidade. Se qualquer um pode alterar o marcoZero da cidade, não seria um risco depender da acuracidade de Rota.getDistancia()?

mochuara:

esmiralha:

Que grande malabarismo é esse??? Prover um método fábrica estático que receba um objeto da própria classe? Muito barulho por nada…

Seu exemplo que não mostra nada, que Rota mais sem graça. :lol:

Se algumas das Cidades forem alteradas sem Rota saber não vai acontecer nada, porque Rota não faz nada com as Cidades, o que vc quer provar com esse exemplo?

Ah-ham. É, é isso mesmo, tá? Isso… Calminho, tá? Toma o remedinho… Tem que tomar todinho. Isso. agora, pra caminha… Isso. Muito bem. Deixa eu botar esse pijaminha de manga bemmmm comprida em você e amarrar nas costas… isso… muito bem. O moço de branco já vem falar com você.

x@ndy:

mochuara:

É claro que Rota depende de atributos da Rodovia que ela contem, senão não faria sentido ela ter uma referencia para rodovia em primeiro lugar.

Como você sabe? No meu dominio ela pode não depender! Já tive vários casos de Objetos Valor com Entidades que não dependiam de nenhum dos atributos das Entidades!
Isso é uma conclusão absurda! Não é por que você nunca utilizou algo assim que pode tirar esse tipo de conclusão.

Vc esqueceu de contar com a possibilidade do design estar equivocado. Tem sentido um objeto refernciar outro, mas não depender de nenhum dos seus atributos?

Se Rota não depende dos atributos da Rodovia, pra que Rota precisa referenciar Rodovia em primeiro lugar?

Da onde?!! Você nunca ouviu falar de agregados não! Acho que você utiliza DDD de ouvir falar e nunca leu o livro do Evans ou qualquer material sobre o assunto!

Bom não sei que “espirito divino” guia seus projetos mas os meus são guiados pelos conhecimentos que obtenho e muito deles eu tiro de livros sim, obrigado!

mochuara:

Se seu objeto é mutavel (e entidades são mutáveis) elas podem ser alteradas por outras threads. Se seu objeto valor depende de atributos da entidade (e certamente dependerá) então vc pode ter bugs no seu sistema, a não ser que use locks!

Imagine que a Rota fornece sua distancia. Ela depende do atributo marcoZero de cada cidade. Se qualquer um pode alterar o marcoZero da cidade, não seria um risco depender da acuracidade de Rota.getDistancia()?

É maravilhoso o seu preciosismo de se basear na regra de que, se um objeto valor possui uma entidade como referencia, ele depende dos atributos dessa entidade!
Os meus projetos eu não uso essas regras preciosas e engessadas, utilizo sempre a melhor solução que eu tenho em mãos. Se eu posso ter um objeto valor que necessite de uma entidade e a invariante é que identidade dessa entidade não pode mudar eu utilizo a solução mais simples que ter uma referencia para entidade ao invés de buscar soluções complexas ou qualquer outra coisa.

Tem sentido sim, a questão é as invariantes. Posso fazer varias operações com um objeto até utilizar os atributos do mesmo mas a questão é se esses atributos quebram alguma invariante do meu objeto. Por acaso você sabe o que invariante? Acho que não!

mochuara:

x@ndy:

Se a Rota depende de qualquer atributo da rodovia de que me adianta ter um id desta ou uma referencia direta a classe? Qualquer um pode alterar em qualquer momento a rodovia o que quebraria as invariantes da Rota! A cópia da Entidade se faz necessário justamente para não quebrar as invariantes do Objeto Valor!

Boa pergunta!

Porque a Rota pode usar o repositorio para obter a Cidade em um escopo local (ou pode ser o caso de não ser responsabilidade da Rota, mas sim de um servico, vai depender do seu dominio). Mas repare que nesse caso não precisa copia. A copia só se faz necessaria porque vc mantem uma referencia para entidade.

Olha, talves eu seja burro, mas para mim um repositorio local contém cópias dos objetos, não!

mochuara:

x@ndy:

Se a rota não depende dos atributos da rodovia, a forma como é feito a referencia é irrelevante, seja através do id da rodovia ou uma referencia direta entre os objetos.

Se Rota não depende dos atributos da Rodovia, pra que Rota precisa referenciar Rodovia em primeiro lugar?

Identidade de uma entidade significa apenas que os atributos da entidade estão associados com diferentes valores no decorrer do tempo. Portanto quando um objeto depende da identidade do outro, ele depende sim dos seus atributos.

x@ndy:

Os meus projetos eu não uso essas regras preciosas e engessadas, utilizo sempre a melhor solução que eu tenho em mãos. Se eu posso ter um objeto valor que necessite de uma entidade e a invariante é que identidade dessa entidade não pode mudar eu utilizo a solução mais simples que ter uma referencia para entidade ao invés de buscar soluções complexas ou qualquer outra coisa.

Bom pra vc, ruim para seu cliente que vai receber um sistema bugado.

AHANNN??? É realmente o caso é de internação…

Então minhas entidades tem que ser imutáveis…hahahahahahhaha

O cara não sabe a diferença de utilizar um atributo e depender do atributo…hahahahah

Cara, vai estudar o que invariante, depois volta para discutir…hahahahahhaha

Como disse antes para utilizar alguns de seus atributos. Esses atributos podem ser irrelevantes para as invariates como disse antes!

Hm… então existem atributos relevantes e não-relevantes? Como vc os diferencia no seu domain model? E se algum atributo passa a ser relevante, não muda tudo?

x@ndy:

mochuara:

Identidade de uma entidade significa apenas que os atributos da entidade estão associados com diferentes valores no decorrer do tempo. Portanto quando um objeto depende da identidade do outro, ele depende sim dos seus atributos.

AHANNN??? É realmente o caso é de internação…

Então minhas entidades tem que ser imutáveis…hahahahahahhaha

O cara não sabe a diferença de utilizar um atributo e depender do atributo…hahahahah

Cara, vai estudar o que invariante, depois volta para discutir…hahahahahhaha

Como conseguiu aprender invariante sem saber o que é identidade?

mochuara:

x@ndy:

Olha, talves eu seja burro, mas para mim um repositorio local contém cópias dos objetos, não!

Considerando que seu BD implementa ACID o repositorio fornece uma fotografia consistente do seu agregado. Não é apenas uma cópia.

mochuara:

x@ndy:

x@ndy:

mochuara:

Se Rota não depende dos atributos da Rodovia, pra que Rota precisa referenciar Rodovia em primeiro lugar?

Como disse antes para utilizar alguns de seus atributos. Esses atributos podem ser irrelevantes para as invariates como disse antes!

Hm… então existem atributos relevantes e não-relevantes? Como vc os diferencia no seu domain model?

Sim, os relevantes fazem parte das invariantes!.

Já ouviu falar de refatoração continua? De se criar o software de maneira incremental e ir evoluindo? Já leu alguma coisa sobre DDD?

mochuara:

x@ndy:

mochuara:

Identidade de uma entidade significa apenas que os atributos da entidade estão associados com diferentes valores no decorrer do tempo. Portanto quando um objeto depende da identidade do outro, ele depende sim dos seus atributos.

AHANNN??? É realmente o caso é de internação…

Então minhas entidades tem que ser imutáveis…hahahahahahhaha

O cara não sabe a diferença de utilizar um atributo e depender do atributo…hahahahah

Cara, vai estudar o que invariante, depois volta para discutir…hahahahahhaha

Como conseguiu aprender invariante sem saber o que é identidade?

hahahahah, eu que não sei o que identidade, hahahahahahhahaha

Senhores, mantenham o nível da discussão fora do lado pessoal =)

Desculpe!

Desculpe!

Que é isso, sou um mero user mortal aqui, não precisa de desculpas.

A discussão é interessante e tal, só precisar tomar vacina anti-troll para conseguir conversar com o mochuara.

Dá para ver que você é gente boa =)

Desculpe!

Que é isso, sou um mero user mortal aqui, não precisa de desculpas.

A discussão é interessante e tal, só precisar tomar vacina anti-troll para conseguir conversar com o mochuara.

Dá para ver que você é gente boa =)

Pior, troll tira qualquer um do sério…rsrsrsrsr
Me manda umas doses ai…rsrsrsrsr

Vc não sabe nem o que é invariante, mas isso não o impediu de citar trocentas vezes aqui neste tópico.

Invariantes são reforçadas por um aggregate root, estamos discutindo um objeto valor que possui uma entidade. Nada a ver. :oops:

mochuara:

x@ndy:

hahahahah, eu que não sei o que identidade, hahahahahahhahaha

Vc não sabe nem o que é invariante, mas isso não o impediu de citar trocentas vezes aqui neste tópico.

Invariantes são reforçadas por um aggregate root, estamos discutindo um objeto valor que possui uma entidade. Nada a ver. :oops:

Ahannn!!! Diga ai o que invariante então, já que eu não sei e estou usando de forma errada! Esclareça a mente deste pobre mortal!