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?
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.
[quote=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?[/quote]
Não tem malabarismo.
[code]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);
}
}[/code]
Que grande malabarismo é esse??? Prover um método fábrica estático que receba um objeto da própria classe? Muito barulho por nada…
[quote=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.[/quote]
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.
[quote=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?[/quote]
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.
[/quote]
Está implicito, ser compartilhado livremente é uma das grandes maravilhas dos objetos valor.
[quote=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á:[/quote]
Ah novamente, me desculpa, eu achei que estavamos falando de DDD no mundo real, e não em exemplos de livro.
[quote=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! [/quote]
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()?
[quote=mochuara][quote=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…
[/quote]
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?
[/quote]
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ê.
[quote=x@ndy][quote=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.
[/quote]
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.
[/quote]
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!
[quote=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()?
[/quote]
É 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!
[quote=mochuara][quote=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![/quote]
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.[/quote]
Olha, talves eu seja burro, mas para mim um repositorio local contém cópias dos objetos, não!
[quote=mochuara][quote=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.
[/quote]
Se Rota não depende dos atributos da Rodovia, pra que Rota precisa referenciar Rodovia em primeiro lugar?
[/quote]
Como disse antes para utilizar alguns de seus atributos. Esses atributos podem ser irrelevantes para as invariates como disse antes!
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.
[quote=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.[/quote]
Bom pra vc, ruim para seu cliente que vai receber um sistema bugado.
Como disse antes para utilizar alguns de seus atributos. Esses atributos podem ser irrelevantes para as invariates como disse antes![/quote]
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?
[quote=x@ndy][quote=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.
[/quote]
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
[/quote]
Como conseguiu aprender invariante sem saber o que é identidade?
[quote=mochuara][quote=x@ndy]
Olha, talves eu seja burro, mas para mim um repositorio local contém cópias dos objetos, não![/quote]
Considerando que seu BD implementa ACID o repositorio fornece uma fotografia consistente do seu agregado. Não é apenas uma cópia.
[/quote]
Ah tá, obrigado pelo esclarecimento. É uma cópia turbinada. Depois sou eu que complico…rsrsrsrsrsr
[quote=mochuara][quote=x@ndy][quote=x@ndy][quote=mochuara]
Se Rota não depende dos atributos da Rodovia, pra que Rota precisa referenciar Rodovia em primeiro lugar?
[/quote]
Como disse antes para utilizar alguns de seus atributos. Esses atributos podem ser irrelevantes para as invariates como disse antes![/quote]
Hm… então existem atributos relevantes e não-relevantes? Como vc os diferencia no seu domain model? [/quote][/quote]
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?
[quote=mochuara][quote=x@ndy][quote=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.
[/quote]
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
[/quote]
Como conseguiu aprender invariante sem saber o que é identidade?[/quote]
hahahahah, eu que não sei o que identidade, hahahahahahhahaha
