DDD: un oggetto valore può contenere elenchi al suo interno?

Question

Non sono esperto nella progettazione guidata dal dominio e di recente ho iniziato a creare un modello di dominio per un progetto. Non ho ancora deciso un ORM (anche se probabilmente andrò con NHibernate) e attualmente sto cercando di assicurarmi che i miei oggetti valore siano esattamente questo.

Ho alcuni VO che non hanno quasi alcun comportamento se non quello di incapsulare "come" termini, ad esempio:

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.

Questa particolare classe ha un riferimento a " Case " che è di due livelli, quindi se dicessi che avrei avuto accesso a un Referral potrei andare: case.social.referral (Case, Social e Referral sono tutte classi, c'è un singolo Social all'interno di un Case e c'è un singolo Referral all'interno un sociale). Ora che lo sto guardando mentre lo scrivo, non penso di aver bisogno di un caso nel referral poiché sarà accessibile attraverso l'entità sociale, giusto?

Ora, non ho dubbi che questo sia qualcosa che dovrebbe essere un VO, e il metodo che ho intenzione di usare per persistere nel database è di fare in modo che NHibernate gli assegni un identificatore surrogato (cosa che ancora non sono troppo chiaro, se qualcuno potesse per favore approfondire anche quello mi aiuterebbe, dal momento che non so se l'identificatore surrogato richiede che ho già un ID nel mio VO o se può funzionare senza uno) e / o un proprietà Id protetta che non verrebbe esposta al di fuori della classe Referral (al solo scopo di persistere nel DB).

Passiamo ora alla domanda sul mio titolo: un VO dovrebbe avere una raccolta (nel mio caso una Lista) al suo interno? Posso solo pensare a questa come una relazione uno-a-molti nel database, ma poiché non esiste un'identità non è sembrato adeguato rendere la classe un'entità. Di seguito è riportato il codice:

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

Questa classe al momento non ha un ID e la classe AdultsAtHome ha solo tipi intrinseci (stringa, int). Quindi non sono sicuro se questo dovrebbe essere un'entità o se può rimanere come VO e ho solo bisogno di configurare il mio ORM per utilizzare una relazione 1: m per questo usando le proprie tabelle e un campo ID privato / protetto in modo che il ORM può persistere nel DB.

Inoltre, dovrei scegliere tabelle normalizzate per ciascuna delle mie classi o no? Penso che dovrei usare una tabella per classe solo quando c'è la possibilità di avere più istanze della classe assegnate a un'entità o un oggetto valore e / o c'è la possibilità di avere relazioni 1: m con alcuni di quegli oggetti . Non ho alcun problema con l'utilizzo di una singola tabella per determinati oggetti valore che hanno tipi intrinseci ma con tipi nidificati penso che sarebbe vantaggioso utilizzare tabelle normalizzate. Qualche suggerimento anche su questo?

Ci scusiamo per essere così prolisso con le domande multiple:

1) Ho bisogno di un identificatore surrogato (con diciamo NHibernate) per i miei oggetti valore?

2) Se il numero 1 è sì, allora deve essere privato / protetto in modo che il mio oggetto valore "rimanga". un oggetto valore nel concetto?

3) Un oggetto valore può avere altri oggetti valore (ad esempio un elenco) o costituirebbe un'entità? (Penso che la risposta sia negativa, ma preferirei esserne sicuro prima di procedere oltre.)

4) Ho bisogno di un riferimento alla radice aggregata da un oggetto valore che si trova a pochi livelli dalla radice aggregata? (Non credo di si, è probabilmente una svista da parte mia quando scrivo il modello, qualcuno è d'accordo?)

5) È corretto utilizzare tabelle normalizzate per determinate cose (come tipi nidificati e / o tipi con raccolte come proprietà che avrebbero comunque bisogno delle proprie tabelle per la relazione 1: m) mentre l'ORM esegue il mapping per il oggetti valore più semplici nella stessa tabella che appartiene alla mia entità?

Grazie ancora.

Answer 1

Dai un'occhiata alle risposte alle domande correlate qui e qui

---

1) Sì - Se stai memorizzando VO nella propria tabella

2) Se puoi utilizzare una proprietà ID privata / protetta, va benissimo. In alternativa, è possibile utilizzare interfacce esplicite per "nascondere" la proprietà ID.

Ma, leggendo la tua domanda, stai suggerendo che gli sviluppatori che vedono una proprietà ID supporranno automaticamente che l'oggetto sia un'entità? In tal caso, hanno bisogno di (ri) formazione.

3) Sì, ma con le seguenti restrizioni:

• Dovrebbe essere abbastanza raro
• Dovrebbe fare riferimento solo ad altri VO

Inoltre, considera questo: i VO non dovrebbero rimanere in giro. Sarebbe facile / efficiente ricreare l'intero VO ogni volta che è necessario? In caso contrario, trasformalo in un'entità.

4) Dipende da come si desidera implementare il Blocco aggregato . Se si desidera utilizzare La soluzione di Ayende , la risposta è sì. Altrimenti, avresti bisogno di un meccanismo per attraversare il grafico dell'oggetto alla radice aggregata.

5) Sì. Non dimenticare che DDD è Ignorante della persistenza (in un mondo ideale!).

---

Tuttavia ...

Credo che il Referral dovrebbe essere un Entity . Immagina queste conversazioni:

Conversazione 1:

• Tom: " Ehi Joe! Puoi darmi il rinvio di David Jone? & Quot;
• Joe: " Quale? "
• Tom: " Siamo spiacenti, intendo riferimento n. 123 "

Conversazione 2:

• Tom: " Ehi Joe! Puoi darmi il rinvio di David Jone? & Quot;
• Joe: " Quale? "
• Tom: " Non mi interessa - dammi solo "

La conversazione 1 suggerisce che Referral è un Entità , mentre la conversazione 2 suggerisce che è un VO.

Un'altra cosa: Referral.ReferralType cambia durante la sua vita (c'è un altro suggerimento che dovrebbe essere un'entità)? Se non cambia, prendi in considerazione l'uso del polisforfismo e lascia che NH lo gestisca.

Spero che ti aiuti!