come modello di relazioni oggettuali di valore?

Question

contesto:
Ho un'entità Book. Un libro può avere una o più descrizioni. Le descrizioni sono oggetti di valore.

problema:
Una descrizione può essere più specifico di un'altra descrizione. Ad esempio, se una descrizione contiene il contenuto del libro e di come il coperchio sembra che è più specifico di una descrizione che discute solo come il coperchio sembra. Non so come modellare questo e come avere il repository salvarlo. Non è la responsabilità del libro, né della descrizione libro per conoscere queste relazioni. Qualche altro oggetto in grado di gestire questo e poi chiedere il repository per salvare i rapporti. Ma BookRepository.addMoreSpecificDescription (descrizione, MoreSpecificDescription) sembra difficile per il repository per salvare.

Come è una cosa del genere gestito in DDD?

Answer 1

Le altre due risposte sono una direzione (+1 btw). Vengo dopo la modifica alla domanda iniziale, per cui qui sono i miei due centesimi ...

definisco un oggetto valore come un oggetto con due o più proprietà che possono (ed è) condivisi tra le altre entità. Essi possono essere condivisi solo all'interno di un unico aggregato radice, va bene anche. Proprio il fatto che essi possono (e sono) in comune.

Per usare il tuo esempio, si definisce una "descrizione" come un oggetto di valore. Che mi dice che "Descrizione" dalle molteplici proprietà può essere condiviso tra diversi libri. Nel mondo reale, che non ha senso, come tutti sappiamo ogni libro ha descrizioni uniche scritte dal comandante che ha scritto o ha pubblicato il libro. Hehe. Quindi, direi che le descrizioni non sono realmente oggetti di valore, ma sono essi stessi oggetti aggiuntivi di entità all'interno del vostro boundery Prenota Aggregate Root Entity (è possibile avere più entità all'interno di un unico soggetto di radice aggregato). Anche i libri che vengono ripubblicato, una revisione più recente, ecc hanno un po 'diverse descrizioni che descrivono quel leggero cambiamento.

Credo che risponde alla tua domanda - rendere le descrizioni oggetti entità e proteggerli dietro la principale Prenota Entity Aggregate Root (ad esempio Book.GetDescriptions () ...). Il resto di questa risposta indirizzi come gestire oggetti di valore nei repository, per gli altri la lettura di questo post ...

Per la memorizzazione oggetti di valore in un repository, e li recupero, iniziamo a invadere sullo stesso territorio ho lottato con me stesso quando sono andato passato da un "Database-primo" approccio di modellazione ad un approccio DDD. Io stesso wreslted con questo, su come memorizzare un oggetto valore nel DB, e recuperarlo senza identità. Fino a quando ho fatto un passo indietro e capito quello che stavo facendo ...

In Domain Driven Design, si sta modellando gli oggetti di valore nella vostra dominio - non è il tuo archivio dati. Questa è la frase-chiave. Vuol dire che non sta progettando il valore oggetti da memorizzare come oggetti indipendenti nel negozio di dati, è possibile memorizzare più vi piace!

Prendiamo l'esempio comune DDD di oggetti di valore, che essendo un indirizzo (). DDD presenta che un indirizzo postale è l'esempio perfetto Valore oggetto, come la definizione di un oggetto di valore è un oggetto di proprietà Chi è riassumono per creare l'unicità dell'oggetto. Se una proprietà cambia, sarà un diverso valore dell'oggetto. E lo stesso valore dell'oggetto 9teh somma delle sue proprietà) può essere condiviso tra gli altri Enti.

Un indirizzo postale è una località, un lungo / lat di una posizione specifica sul pianeta. Più persone possono vivere a indirizzo, e quando qualcuno si muove, il nuovo popolo di occupare lo stesso indirizzo postale ora utilizzare lo stesso valore oggetto.

Quindi, ho un oggetto Person () con un oggetto MailingAddress () che ha le informazioni di indirizzo in esso. Esso è protetto dietro il mio Person () radice aggregato con GET / aggiornamento / Crea metodi / servizi.

Ora, come possiamo memorizzare e condividere che è tra le persone nella stessa economia domestica? Ah, ci si trova DDD - non sta modellando il tuo archivio dati direttamente dal vostro DDD (anche se, che sarebbe bello). Detto questo, è semplice creare una singola tabella che presenta l'oggetto persona, ed ha le colonne per il vostro indirizzo postale all'interno di esso. E 'il lavoro del repository per reidratare le informazioni di nuovo nella vostra Persona () e MailingAddress () oggetto dall'archivio dati, e per dividere in su durante le operazioni di creare / aggiornare.

Sì, devi avere dati duplicati ora nel tuo archivio dati. Tre persona () soggetti con lo stesso indirizzo postale tutti ora hanno tre copie separate di che i dati valore dell'oggetto - e questo è ok! Oggetti di valore sono destinate ad essere copiato e destoyed abbastanza facilmente. "Copia" è la parola ottimale lì nel playbook DDD.

Quindi, per riassumere, Dominio Unità design è di circa modellare il vostro dominio per rappresentare il vostro uso aziendale effettivo degli oggetti. Si modella un Person () entità e un valore MailingAddress oggetto separatamente, in cui sono rappresentati in modo diverso nella vostra applicazione. Persistono loro un-dati copiati, che essendo colonne aggiuntive nella stessa tabella come il vostro tavolo persona.

Tutto quanto sopra è rigorosa-DDD. Ma, DDD è pensato per essere solo "suggerimenti", non regole di vivere. È per questo che sei libero di fare quello che io e molti altri hanno fatto, specie di uno stile loose-DDD. Se non vi piacciono i dati copiati, l'unica opzione è che l'essere è possibile creare una tabella separata per MailingAddress () e attaccare una colonna di identità su di esso, e aggiornare il MailingAddress) oggetto (per avere ora hanno che l'identità su di esso - sul fatto che usa solo che l'identità di collegarlo ad altri Person () oggetti che condividono esso (io personalmente come un terzo molti-a-molti tabella di relazioni, per mantenere la velocità delle query in su). Si potrebbe mascherare che idenity (vale a dire il modificatore interno) di essere esposti al di fuori della vostra Aggregate Root / dominio, in modo che altri livelli (ad esempio l'applicazione o interfaccia utente) non si conosce della colonna Identità del MailingAddress, se possibile. Inoltre, vorrei creare un repository dedicato solo per MailingAddress, e usare il vostro livello di PersonService per combinarle in l'oggetto giusto, Person.MailingAddress ().

Ci scusiamo per lo sfogo ...:)

Answer 2

In primo luogo, credo che le recensioni dovrebbero essere entità.

In secondo luogo, il motivo per cui stai cercando di modellare le relazioni tra recensioni? Non vedo un rapporto naturale tra di loro. "Più specifico di" è troppo vago per essere utile come una relazione.

Se hai difficoltà a modellare la situazione, che suggerisce che forse non v'è alcuna relazione.

Answer 3

Sono d'accordo con Jason. Non so che cosa il vostro logica è per rendere gli oggetti di valore le recensioni.

mi aspetterei un BookReview di avere BookReviewContentItems in modo che si potrebbe avere un metodo sul BookReview di chiamare per decidere se è abbastanza specifico, in cui il metodo decide in base interrogare la sua collezione di elementi di contenuto.