Objeto de valor exclusivo x entidade


8

Tentando converter algumas entidades em objetos de valor, estou preso em um caso em que o que parece um objeto de valor deve ser único dentro de um agregado.

Suponha que tenhamos uma entidade Movie que faça a raiz de um agregado. Essa entidade Movie está relacionada a algum conjunto de objetos AdvertisementEvent com a função de exibir um anúncio em determinado carimbo de data / hora.

O AdvertisementEvent contém um link para algum banner que deve ser exibido, as coordenadas e alguns filtros de efeito.

Como AdvertisementEvent é apenas uma coleção de parâmetros de configuração, não tenho certeza se devo me preocupar com sua identidade e tratá-la como apenas um objeto de grande valor. No entanto eu me importo que dentro de um filme deve haver apenas um AdvertisementEvent em uma determinada data e hora, provavelmente ainda em torno a data e hora.

Acho difícil dividir minhas dúvidas em várias perguntas independentes, então lá vão elas:

  1. Uma coleção de parâmetros de configuração soa como um objeto de valor?
  2. Estou misturando o conceito de exclusividade do AdvertisementEvent no Movie e a regra de integridade transacional?
  3. Será que qualquer das opções no ponto (2) implica que AdvertisementEvent deve ser um membro do agregado feito por filme ?
  4. Meu objeto AdvertisementEvent é uma entidade, um objeto de valor ou um objeto de evento? (Usei o sufixo Event no nome para destacar minha confusão)
  5. Objetos de grande valor como este são cheiros de design?

Acho que não estou lidando com um evento no sentido de DDD, porque não é algo que simplesmente acontece . O verdadeiro evento DDD deve ser algo mais como AdvertisementEventReached

Respostas:


9

A distinção entre o objeto Entidade e Valor deve ser baseada na pergunta: Se eu tiver dois objetos com o mesmo conteúdo (dois AdvertisementEvents vinculados ao mesmo Banner com os mesmos parâmetros), devo tratá-los de maneira diferente ou se um pode ser substituído pelo outro sem afetar como o software funciona?

Nesse caso, eu diria que você pode substituir um AdvertisementEvent por outro pelos mesmos valores sem afetar a operação do software. Isso os torna objetos de valor (o valor contido é o que conta, não a identidade do próprio objeto).

Quanto ao tamanho de um objeto Value: contanto que ele contenha um conjunto coerente de parâmetros para uma única responsabilidade, não há limite para o tamanho de um objeto Value. Na implementação, pode ser bom prestar atenção especial a objetos de grande valor, para garantir que eles não sejam desnecessariamente e excessivamente copiados, mas, caso contrário, não há problema.

Quanto às restrições sobre o número de AdvertisementEvents que você possui em um Filme , essa é uma restrição à relação entre um Filme e sua coleção de AdvertisementEvents , não em uma dessas classes individualmente. Como tal, o local mais lógico para aplicar a restrição é no ponto em que a coleção é mantida no Movie (portanto, no método em que você tenta adicionar um AdvertisementEvent ).


Muito obrigado! Apesar de ler tantas vezes sobre fazer essa pergunta para diferenciar Entidades de Objetos de Valor, desta vez finalmente "clicou". Acho que precisava de um problema na minha vida real para aprender essa lição. Adoro o meu problema porque ele foi exposto em Event Object (que não é um Evento de Domínio) e o que parece ser uma exclusividade (que é invariável). Eu acho que na minha pergunta eu deveria ter dito "invariável" em vez de "regra de integridade transacional".
SystematicFrank

Interessante ... como um efeito colateral de entender melhor essa diferença, agora posso ver claramente a importância de objetos de valor sem estado / imutáveis ​​para melhorar a estabilidade dos meus programas. Acho que estava pensando demais nos detalhes da implementação da GUI ... fácil mutação é agradável na Camada de Aplicação, mas na Camada de Domínio quero que o AdvertisementEvent seja imutável!
SystematicFrank
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.