DDD e la persistenza di oggetti valore; dobbiamo denormalizzare?

Non penso davvero che ci sia un problema con gli OV che hanno un'identità nel database, a patto che questa identità rimanga nascosta e trasparente nello stesso livello del dominio. Sarei responsabile del livello dati per tenere traccia di tali identità in modo che il dominio non debba preoccuparsene.

Ma i VO ti danno ancora la possibilità di denormalizzare. La denormalizzazione può avere i suoi vantaggi, solitamente per motivi di prestazioni. Quindi puoi usarlo a tuo vantaggio.

Questo è un problema se si utilizza un ORM per mappare gli oggetti del dominio direttamente sul DB. Questo cade a pezzi piuttosto rapidamente per tutti tranne che per le applicazioni più banali. Crea invece classi separate per rappresentare il tuo archivio dati e mappali. Avrai bisogno di un codice che associ i BO ai DTO, ma non sarai costretto a compromettere le tue classi di dominio per rendere felice l'ORM, che è invariabilmente ciò che accade. Eviterete anche l'astrazione che perde con l'uso di un ORM.

Considerato quanto sopra, dipende il modo in cui si mantengono gli oggetti valore. Se stai memorizzando, ad esempio, le coordinate geografiche, probabilmente non le normalizzo e le memorizzerò nella stessa tabella dell'entità. Se i tuoi tipi di valore hanno in realtà una propria identità, ciò mi suggerisce che probabilmente non dovrebbero essere oggetti di valore nel tuo livello di dominio. Questo è veramente il che definisce la differenza tra un oggetto valore e un'entità in DDD. Mi piace sempre andare alla fonte per DDD; sfortunatamente molti dei blog che vedrete su internet (specialmente quelli che amano davvero NHibernate) non hanno davvero alcun DDD, e seguendo i loro consigli di solito vi portano al anti-pattern del modello di dominio anemico .