Nella progettazione basata sul dominio, come posso convertire una tabella di database con una chiave primaria in un oggetto valore?

Question

Nella progettazione basata sul dominio, come posso convertire una tabella di database con una chiave primaria in un oggetto valore?

#1 da (2 voti)
#2 da (2 voti)
#3 da (-1 voti)

8

Supponiamo che ci sia uno schema di database definito in questo modo:

Person.mail_address_key ----- Address.address_key
Person.billing_address_key ----- Address.address_key

Un Person ha un indirizzo postale e un indirizzo di fatturazione. Come tecnica di denormalizzazione, creiamo una tabella Address separata. Il più delle volte il mail_address_key e il billing_address_key di un singolo Person avranno lo stesso valore (es .: il loro indirizzo e indirizzo di fatturazione sarà lo stesso).

Nel mio database Address ha un'identità (la chiave dell'indirizzo). Ma, nel mio modello di dominio , non vedo un motivo convincente per il fatto che Address sia un'entità, mi piacerebbe che fosse un oggetto valore.

In DDD, questa è un'opzione? O sono oggetti valore di solito un gruppo di colonne (al contrario di una tabella)? In questo caso, interpreto l'avvocato del diavolo, perché non penso che il database debba dettare la struttura del modello di dominio, ma solo per essere sicuro.
In tal caso, dove / quando / in che modo l'indirizzo perde la sua identità di database in modo che possa essere utilizzato come oggetto valore nel livello dominio? O, dovrei mantenere l'identificatore del database nell'oggetto valore?
Quando il modello deve essere persistente nel database, qual è il processo? Dovrei passare attraverso un processo di a) Trovare un indirizzo con questi campi, b) se non esiste, crearne uno nuovo c) se lo fa, aggiornare i campi?

domain-driven-design domain-model value-object

posta Daniel Kaplan 06.10.2014 - 21:06

fonte

3 risposte

2

DDD non applica affatto lo schema DB. L'oggetto valore può essere implementato come un gruppo di colonne, entità db (la terza soluzione) o semplicemente in un modulo denormalizzato se è possibile utilizzare un database orientato ai documenti per esempio. Dipende dalle diverse circostanze qual è l'opzione migliore da seguire.

Ricorda che DB è solo uno strumento per mantenere il tuo stato di dominio. Non dovrebbe forzare alcuna decisione sul design. Se per qualche ragione devi utilizzare l'identità per la rappresentazione dell'oggetto di valore nel DB, farlo, ma non perdere questi dettagli di implementazione nel dominio stesso. Crea un wrapper / estendi le classi di dominio / qualunque sia il tuo framework e aggiungi l'ID in una classe infrastrutturale completamente separata che consente all'applicazione / framework di mantenere lo stato.

risposta data 07.10.2014 - 23:53

fonte

-1

In questo caso non vedo requisiti speciali del DDD, puoi modellare gli indirizzi di posta e fatturazione come proprietà di una persona e memorizzarli ancora in una tabella separata, ad esempio:

Person
+ MailingAddress : Address
+ BillingAddress : Address

o

Person
+ MailingAddressID
+ MailingAddress : Address
+ BillingAddressID
+ BillingAddress : Address

risposta data 08.10.2014 - 03:16

fonte

Leggi altre domande sui tag domain-driven-design domain-model value-object

Come risolvere nomi tipici generici nel compilatore? Pratiche per i modelli di dominio in Javascript (con framework)

score 2 · Accepted Answer

In DDD, is this an option? Or are Value Objects usually a group of columns (as opposed to a table)? I'm kind of playing the devil's advocate here, because I don't think the database should dictate the domain model structure, but just making sure.

Il database non dovrebbe dettare la struttura del modello di dominio in modo da essere corretto su questo. Gli oggetti valore possono essere memorizzati nel database come una colonna o tabella a seconda del tipo di dati che l'oggetto valore deve trasportare.

If so, where/when/how does the address lose its database identity so it can be used as a Value Object in the Domain Layer? Or, am I supposed to keep the database identifier in the Value Object?

Il tuo codice dominio non dovrebbe essere pieno di proprietà che riguardano altri problemi come la persistenza, dal momento che dovrebbero essere completamente ignoranti per la persistenza. Dovresti davvero concentrarti sulla tua radice aggregata. Devi avere un modo per identificare la tua radice aggregata quando la salvi di nuovo nel database così, a quel punto, dovresti solo controllare il record della tabella Person (presumo che Person sia la tua radice aggregata) e vedere se c'è un valore nel campo MailingAddressID o BillingAddressID. A quel punto, puoi decidere se creare nuovi indirizzi e modificare i link per puntare ai nuovi indirizzi o sovrascrivere gli indirizzi già collegati.

When the model needs to be persisted in the database, what's the process? Am I supposed to go through a process of a) Find an address by these fields, b) if it doesn't exist, create a new one c) if it does, update the fields?

Come ho spiegato in qualche modo nella risposta di cui sopra, dovresti idratare e disidratare il tuo grafico degli oggetti in base alla tua radice aggregata. Pertanto, quando il repository ottiene la radice aggregata dal database, idraterà anche tutte le entità e gli oggetti valore necessari nella radice aggregata associati alla radice aggregata nel database. Lo stesso è vero quando si va a salvare la radice aggregata sul database. Il tuo repository dovrebbe essere in grado di gestire l'intero grafico dell'oggetto sotto la radice aggregata.