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.[/quote]
Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!
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!
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![/quote]
Não creio que ele tenha um objeto nuvem no dominio (a menos que ele esteja modelando o ceu! rs).
[quote=x@ndy] Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!
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!
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![/quote]
[quote=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![/quote]
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.
[quote=mochuara][quote=x@ndy][quote=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.[/quote]
Como o post anterior ficou confuso vou tentar explicar melhor o meu ponto de vista baseado na curta análise que fiz!
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!
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![/quote]
Não creio que ele tenha um objeto nuvem no dominio (a menos que ele esteja modelando o ceu! rs).[/quote]
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.
[quote=mochuara][quote=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![/quote]
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.[/quote]
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!
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?
Pera ai vamos me confirme se eu entendi o que você quer dizer!
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.
As referencias são resolvidas pelo REPOSITÓRIO!
É isso?
[quote=x@ndy]Pera ai vamos me confirme se eu entendi o que você quer dizer!
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.
As referencias são resolvidas pelo REPOSITÓRIO!
É isso?[/quote]
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.
Leg é um VO (implementa ValueObject) e referencia (“contém um private member do tipo de”) 2 Locations (implementa Entity) e 1 Voyage (implementa Entity).
[quote=mochuara][quote=x@ndy]Pera ai vamos me confirme se eu entendi o que você quer dizer!
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.
As referencias são resolvidas pelo REPOSITÓRIO!
É isso?[/quote]
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.[/quote]
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”
Leg é um VO (implementa ValueObject) e referencia (“contém um private member do tipo de”) 2 Locations (implementa Entity) e 1 Voyage (implementa Entity).
[/quote]
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.
[quote=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.[/quote]
Acho que todo o problema está ocorrendo por que você está fazendo uma confusão com o o que ele quer dizer com a imutabilidade de um OBJETOS VALOR e como ele se associa a uma ENTIDADE!
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.
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).
[quote=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?[/quote]
Eu ficaria surpreso se descobrisse que era essa visão de imutabilidade do Eric Evans quando escreveu o livro.
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). [/quote]
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.
[quote=mochuara][quote=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?[/quote]
Eu ficaria surpreso se descobrisse que era essa visão de imutabilidade do Eric Evans quando escreveu o livro.[/quote]
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.