[DDD] Quantidade de Value Objects x Qualidade do modelo

cmoscoso:

Oi,

Tenho tido duvidas ao classficar alguns objetos de domínio de acordo com as idéias de Eric Evans, digo em relação a classificacao de um objeto como entidade x value object.
Estou ciente que de acordo com o tipo de projeto você pode ter mais ou menos value objects, tipo alguns projetos são só value objects do outro lado existem aqueles basicamente CRUDs e por isso com mais entidades, O meu caso é um projeto enterprise/comercial que apesar de não ter uma carga grande de acessos possui requisitos bem específicos, não são CRUD apenas… Dito isso, mais alguém aqui possui tal dificuldade? é uma boa coisa considerar aqueles objetos que você não tem certeza como value objects “até que se prove o contrário”? ou seja, até que fique claro que ele deveria ser uma entidade.

Apesar de achar trabalhoso implementar imutabilidade naqueles value objects com estrutura mais complexa eu gosto de trabalhar com eles porque tem um ciclo de vida simples se comparadas com entidades, por isso também são mais “previsíveis”.

Mais alguém acredita que seu modelo deveria ter mais value objects?

O numero de objetos no modelo não é medida de nada, por isso não se preocupe com o numero.
Agora, a qualidade dos objetos pode ser influenciada pelo numero. Tlv vc divida em muitas partes o seu modelo quando não seria necessário ou não divida o suficiente quando é.
Os VO são imutáveis porque representam valores. Se a imutabilidade deles é um problema tlv eles não sejam um VO. Por exemplo, é dificil imaginar um VO que seja um Grafo complexo. Poderá até ser, mas é preciso uma muito boa razão para isso. Normalmente o VO encapsula algumas propriedades e muitos métodos de mutabilidade. VEjam-se as classes de data do Joda-Time e outros … a data em si são 3 numeros, isso é o VO, mas operações sobre esses numeros têm regras complexas. Tão complexas que precisam ser encapsuladas em outros objetos (Chronology). Um projeto pode ter este tipo de objeto complexo (normalmente tem já que é ai que está o “negocio”) e é preciso separar o objeto que transporta os dados ,o VO, daqueles que dizem como operar sobre os dados. Mas cuidado porque CRUD não é , nem nunca será , um a rega de negócio. É apenas uma necessidade do sistema.

è verdade que tem que analizar bem os seus VO, não os confundir com DTO e não assumir que eles são necessários para o CRUD.

Por exemplo no caso de Specifications… eu não li no livro de domaindrivendesign que Specifications são value objects mas ao mesmo tempo todos os exemplis de specifications utilizados me levam a considerar specifictions como value objects.

Um tipo de specification em especial, pouco falado por sinal, é utilizado para specificar a criacao de novos objetos ao inves de trabalhar na especificacao de objetos que ja existem. Como aquele utilizado no exemplo do livro, the cargo shipping system. Esse tipo de specification pode levar a value objects complexos (considerando specifications como value objects) e o autor diz num trecho:

Esse 3o tipo de specification é bastante comum e temos que ser capazes de identificar uma situacao onde aplica-lo. Um caso mais complexo poderia ser implementado com builder pattern. Como eu considero specifications imutaveis eu me vi fazendo algo basdeado numa fluent interface (posso chamar isso de uma DSL interna?)

cmoscoso:

Por exemplo no caso de Specifications… eu não li no livro de domaindrivendesign que Specifications são value objects mas ao mesmo tempo todos os exemplis de specifications utilizados me levam a considerar specifictions como value objects.

Não diria isso. Specifications não têm valor , têm regras. As regras podem ter parametros, mas isso não as torna VO.

Acho que sim. Se a interface é fluente é logicamente um tipo de linguagem, e se vc criou essa fluência com um fim especifico (aquilo que o objeto faz) então é uma DSL (Domain Specific Language). Se bem que DSL pode compreender vários objetos, então o melhor é chamar de fluente interface (interface fluente) para não confundir.