DDD e oggetti valore. Gli oggetti valore mutabili sono un buon candidato per Non Aggr. Entità di radice?

9

Ecco un piccolo problema

Avere un'entità, con un oggetto valore. Non è un problema. Sostituisco un oggetto valore per uno nuovo, quindi nibisco inserisce il nuovo valore e orfano il vecchio, quindi lo elimina. Ok, questo è un problema.

Assicurato è la mia entità nel mio dominio. Ha una collezione di indirizzi (oggetti valore). Uno degli indirizzi è MailingAddress. Quando vogliamo aggiornare l'indirizzo postale, supponiamo che lo zipcode sia sbagliato, seguendo la dottrina di Evans, dobbiamo sostituire il vecchio oggetto con uno nuovo poiché è immutabile (un oggetto valore giusto?).

Ma non vogliamo eliminare la riga, perché il PK di quell'indirizzo è un FK in una tabella MailingHistory. Quindi, seguendo la dottrina del Sig. Evans, siamo praticamente fregati qui. A meno che non crei le Entità dei miei indirizzi, quindi non devo "sostituirli", e semplicemente aggiornare il suo codice di avviamento postale, come i vecchi bei giorni.

Che cosa mi suggeriresti in questo caso? Il modo in cui lo vedo, ValueObjects è utile solo quando si desidera incapsulare un gruppo di colonne della tabella del database (componente in nhibernate). Tutto ciò che ha un ID di persistenza nel database, è meglio renderlo un'entità (non necessariamente una radice aggregata) in modo da poter aggiornare i suoi membri senza ricreare l'intero grafo degli oggetti, specialmente se si tratta di un oggetto con nidificazione profonda.

Siete d'accordo? È consentito a Mr. Evans di avere un oggetto con valore mutabile? O è un oggetto valore mutabile candidato per un'entità?

Grazie

    
posta Pepito Fernandez 12.12.2012 - 07:24
fonte

3 risposte

7

Tutto ciò che ha un'identità dovrebbe essere un'entità e tutto ciò che non ha un'identità è un valore semplice, quindi un oggetto valore.

Per citare Martin Fowler (che a sua volta fa eco a Eric Evans)

  • Entità: oggetti con un'identità distinta che scorre nel tempo e con diverse rappresentazioni. Sentite anche questi chiamati "oggetti di riferimento".
  • Oggetto valore: gli oggetti che contano hanno solo la combinazione dei loro attributi.

Motivo per rendere il tuo indirizzo un oggetto valore:

Se il tuo indirizzo è mutabile, probabilmente rovinerai la cronologia della tua posta alla fine. Ad esempio, se stai spedendo gli articoli a un cliente, non puoi essere sicuro di quale indirizzo hai effettivamente spedito qualcosa in passato se l'indirizzo a cui si riferisce la tabella MailingHistory è stato modificato.

La voce MailingHistory Abbiamo spedito A764 all'indirizzo 657 potrebbe significare Abbiamo spedito l'articolo A764 a Boston ieri e Abbiamo spedito l'articolo A764 a New York domani.

Se l'indirizzo postale deve essere cambiato, non è necessario cancellare quello vecchio. Conservalo e contrassegnalo come non attivo e il nuovo come attivo .

Ovviamente potresti trattare il tuo indirizzo come una Entità, ma solo quando l'aggiornamento non cambierebbe la posizione attuale a cui si riferisce l'indirizzo, consentendo quindi solo la correzione degli errori di battitura.

Se sei sicuro di poterlo fare, non sarebbe possibile utilizzare un'entità.

Ma la soluzione migliore IMHO è di non riferire un indirizzo Entità nella cronologia della tua mailing, ma piuttosto di salvare l'indirizzo specifico direttamente nella tabella della cronologia delle tue mailing (basicamente copiando i dati dell'indirizzo).

In questo modo, sai sempre dove hai spedito la tua roba (o qualunque cosa tu stia inviando), e dato che useresti un'entità mutabile, la tua tabella di indirizzi non sarà ingombra.

Ho lavorato con / su diversi sistemi ERP e quasi tutti hanno usato questo approccio.

Avrai una certa ridondanza nel tuo database, ma è il modo più pragmatico di IMHO.

    
risposta data 12.12.2012 - 10:18
fonte
2

Vedo 2 cose:

  1. Va bene che la modifica del codice postale abbia effetto su un record della cronologia? Penso che sarebbe logico che il record della cronologia indicasse il vecchio indirizzo invariato, quindi sai di inviarlo all'indirizzo sbagliato.

  2. Nel momento in cui MailingHistory ha FK sull'indirizzo, l'indirizzo smesso di essere un oggetto valore e diventa entità. Gli oggetti valore non hanno identità, che consentono ad altre entità di fare riferimento a questa identità. Puoi avere indirizzi in una singola tabella con altre tabelle che puntano ad esso, ma solo l'effetto è risparmio di spazio. Dal punto di vista del dominio, se due entità hanno lo stesso tipo di oggetto valore di riferimento, allora non condividono alcun tipo di informazione.

risposta data 12.12.2012 - 10:20
fonte
2

IMO l'oggetto indirizzo è un'entità nel tuo dominio. È condiviso da più entità, ha la sua identità ed è unico in tutto il sistema.

Evans dice:

An object defined primarily by its identity is called an entity.

    
risposta data 12.12.2012 - 10:18
fonte

Leggi altre domande sui tag