Come gestire un oggetto valore che deve cercare i dati nel database

Question

Sono appena agli inizi con lo studio della progettazione basata sul dominio ed è del tutto possibile che la mia comprensione della divisione Entità/Valori sia errata, quindi se questo è così per favore fammi sapere.

Dalla mia comprensione, poiché la sua identità è completamente definita dalle sue proprietà, un indirizzo è l'oggetto valore quintessenziale. Dalla mia comprensione, ciò significa tra l'altro che non ci dovrebbe essere un repository separato o un oggetto di accesso ai dati per gli indirizzi.

Questo crea un problema per me dal momento che nel mio caso un indirizzo contiene un Paese in cui un Paese ha un nome e un codice paese e l'elenco dei codici paese deve essere caricato dal database.

La mia domanda è, come si progetta questo? Voglio che le persone siano in grado di creare un indirizzo usando il nuovo operatore, ma non voglio creare un oggetto di accesso ai dati per il Paese e, se lo faccio, non voglio certamente fare riferimento ad esso nell'oggetto dell'indirizzo.

Ho alcune idee, ma mi piacerebbe sentire qualche suggerimento che qualcuno potrebbe avere.

Answer 1

Questo crea un dilemma per me dal momento che in mio caso di un indirizzo contiene un Paese in cui un paese ha un nome e un country-code e l'elenco delle paese codici si suppone di essere caricato in dal database.

L'oggetto Address non avrebbe un elenco di paesi come proprietà. Piuttosto, avrebbe una singola istanza dell'oggetto Paese. Il Presentation Layer fornirebbe un elenco di oggetti Country, probabilmente residenti in un elenco a discesa. Dopo aver caricato un indirizzo specifico, si imposta il valore dell'elenco a discesa uguale all'ID paese dell'oggetto Paese che è una proprietà dell'oggetto Address. In altre parole:

(contenente un elenco di oggetti Nazione) valore dell'oggetto selezionato = address.Country o myDropDown del valore della chiave di myDropDown = address.Country.ID

Ora, per popolare il livello di presentazione, il tuo accesso ai dati Il livello dovrebbe fornire una funzione che restituisce un elenco non elaborato di oggetti Paese. In un certo senso .NET, sarebbe qualcosa di simile:

Namespace Dal 

    Public NotInheritable Class Countries 
    ... 
    Public Shared Function Read(ByVal countryId as Integer) As BusinessObjects.Country 
    ... 
    Public Shared Function ReadList() As List(Of BusinessObjects.Country) 
    ... 

Answer 2

Vorrei iniziare dicendo che la mia unica esperienza con il dominio Driven Design stava leggendo l'articolo di Wikipedia pochi minuti fa. Detto questo, ecco i miei pensieri sulla tua domanda:

Sono d'accordo che l'oggetto indirizzo non dovrebbe richiedere alcun oggetto di accesso ai dati, quindi come su un factory indirizzo che gestisce i codici paese e costruisce gli oggetti indirizzo in base agli input da l'utente? In questo modo, la fabbrica manterrebbe gli oggetti di accesso ai dati e il tuo oggetto indirizzo potrebbe rimanere di valore.

Se questo non è kosher secondo DDD, quindi fatemelo sapere. Sono curioso di vedere cosa viene fuori dal resto della community.

Answer 3

non c'è nulla nella DDD che preclude agli oggetti valore di contenere riferimenti a entità. Pertanto il tuo indirizzo avrebbe un riferimento a un'entità di un paese.

Answer 4

Passando al modo DDD, prima penserai alle esigenze della tua applicazione e costruirai il modello da lì.

Non dovresti preoccuparti del Paese utilizzato solo in Indirizzo. Non è sbagliato renderlo un'entità di per sé. La domanda principale è: pensi a un Paese come a qualcosa che ha un'identità o è definito solo dagli attributi? Se hai due paesi con lo stesso nome (e lo stesso prefisso internazionale), puoi vedere qualche differenza?

Forse dovresti considerare di rendere Country un oggetto di valore. Non ti impedisce di avere un repository che carica l'elenco dei Paesi dal DB o che carica il Paese in base al suo codice. Sul lato dell'implementazione, il repository può ancora caricare l'elenco dei paesi dal database una volta e archiviarlo nella memoria. O potrebbe avere hardcoded, o leggere da XML. Il tuo modello di dominio non interesserebbe.

Probabilmente creerai un metodo di fabbrica su Indirizzo che accetta il codice paese tra gli altri parametri. Quindi utilizzerà il repository per creare un'istanza Country e restituire un oggetto Address corretto.

Pensare agli aggregati può anche fornire alcune idee sul layout del repository.

Spero che questo aiuti