DDD: Pode um objeto de valor têm listas dentro deles?

Question

Eu não estou bem versado em domínio driven design e eu recentemente começou a criar um modelo de domínio para um projeto. Eu ainda não ter decidido sobre um ORM (embora eu provavelmente vai ir com NHibernate) e atualmente estou tentando garantir que meus objetos de valor deve ser apenas isso.

Eu tenho algumas VOs que têm quase nenhum outro comportamento do que para encapsular "como" termos, por exemplo:

public class Referral {
    public Case Case { get; set; } // this is the a reference to the aggregate root
    public ReferralType ReferralType { get; set; } // this is an enum
    public string ReferralTypeOther { get; set; }
} // etc, etc.

Esta classe em particular tem uma referência ao "caso" que é de dois níveis acima, então se dizer que eu estava indo para acessar um Referral eu poderia ir: case.social.referral (Case, Social e de Indicação são todas as classes, há um único social dentro de uma caixa e não há uma única remessa dentro de um social). Agora que eu estou olhando para ele como eu digitá-lo, eu não acho que eu preciso de um caso no Referral uma vez que será acessível através da entidade social, correto?

Agora, não há dúvida em minha mente que este é algo que deve ser um VO, e o método que pretende usar a persistir esta ao banco de dados é que quer ter NHibernate atribuir-lhe um identificador de aluguel (que eu ainda não estou muito claro sobre, se alguém poderia por favor elaborar sobre isso também ele iria me ajudar, desde que eu não sei se o identificador substituto exige que eu tenho um ID na minha VO já ou se pode operar sem um) e / ou um propriedade protegida Id que não seriam expostos fora da classe de referência (com o único propósito de persistir ao DB).

Agora sobre a minha pergunta do título: Se um VO tem uma coleção, (no meu caso um List) dentro dela? Só posso pensar nisso como uma relação de um-para-muitos no banco de dados, mas já que não há identidade não parecia adequada para fazer a classe entidade. Abaixo está o código:

public class LivingSituation {
    private IList<AdultAtHome> AdultsAtHome { get; set; }
    public ResidingWith CurrentlyResidingWith { get; set } // this is an enum
} // etc, etc.

Esta classe atualmente não tem um ID e a classe AdultsAtHome só tem tipos intrínsecos (String, int). Então, eu não tenho certeza se esta deve ser uma entidade ou se ele pode permanecer como um VO e eu só preciso configurar meu ORM para usar um relacionamento 1: m para este utilizando os seus próprios quadros e um campo Id privado / protegido para que o ORM pode persistir ao DB.

Além disso, devo ir com tabelas normalizadas para cada uma das minhas aulas, ou não? Acho que só precisa usar uma tabela por classe quando existe a possibilidade de ter várias instâncias da classe atribuído a um objeto entidade ou valor e / ou existe a possibilidade de ter coleções de 1: m relacionamentos com alguns desses objetos . Não tenho nenhum problema com o uso de uma única tabela para determinados objetos de valor que têm tipos intrínsecos, mas com tipos aninhados eu acho que seria vantajoso usar tabelas normalizadas. Todas as sugestões sobre este tão bem?

Desculpe por ser tão detalhado com as questões de múltipla:

1) Eu preciso de um identificador substituto (com digamos NHibernate) para os meus objetos de valor?

2) Se nº 1 for sim, então é que esta necessidade de ser privado / protegidos de modo que o meu valor de objeto "restos" um objeto de valor no conceito?

3) Pode um objeto de valor têm outros objetos de valor (em digamos, um List) ou teria que constituem uma entidade? (Eu acho que a resposta a esta não é, mas eu prefiro ter certeza antes de prosseguir.)

4) Preciso de uma referência à raiz agregada a partir de um objeto de valor que está alguns níveis abaixo da raiz agregada? (Eu não acho que eu faço, é provável que um descuido da minha parte quando se escreve o modelo, qualquer um concorda?)

5) É OK para usar tabelas normalizados para certas coisas (como tipos aninhados e / ou tipos com coleções como propriedades que teriam os seus próprios quadros de qualquer maneira para o relacionamento 1: m), tendo a ORM fazer o mapeamento para a valor mais simples objetos para a mesma tabela que pertence a minha entidade?

Obrigado novamente.

Answer 1

Dê uma olhada nas respostas a perguntas relacionadas aqui e aqui

---

1) Sim - Se você está armazenando VOs em sua própria mesa

2) Se você pode usar uma propriedade ID privado / protegido, então ótimo. Alternativamente, você pode usar interfaces explícitas para 'esconder' a propriedade ID.

Mas, lendo a sua pergunta, você está sugerindo que os desenvolvedores que vêem uma propriedade ID irá automaticamente assumir o objeto é uma entidade? Se assim for, eles precisam (re) formação.

3) Sim, pode, mas com as seguintes restrições:

• Deve ser bastante rara
• Ele só deve referenciar outros VOs

Além disso, considere o seguinte: VOs não deve ficar por aqui. Seria fácil / eficiente para recriar todo o VO cada vez que é necessário? Se não, torná-lo uma Entidade.

4) depende de como você deseja implementar o seu Aggregate Locking . Se você quiser usar o Ayende solução , a resposta é sim. Caso contrário, você precisaria de um mecanismo para percorrer a volta gráfico do objeto ao Aggregate Raiz.

5) Sim. Não se esqueça que DDD é Persistência ignorante (em um mundo ideal!).

---

No entanto ...

Eu acredito Consulta deve ser um Entidade . Imagine que essas conversas:

Conversação 1:

• Tom: "Hey Joe você pode me dar referência de David Jone?"
• Joe: "Qual?"
• Tom: "Desculpe, eu quero dizer Referral No.123"

Diálogo 2:

• Tom: "Hey Joe você pode me dar referência de David Jone?"
• Joe: "Qual deles"
• Tom: "Eu não me importo - apenas dar-me qualquer"

Conversation 1 sugere que o encaminhamento é uma Entidade , enquanto conversa 2 sugere que é um VO.

Mais uma coisa: muda Referral.ReferralType durante a sua vida (há um outro indício de que ele deve ser uma entidade)? Se não mudança, considere o uso polyporphism e deixe NH lidar com isso.

Espero que ajude!