"Implementare DDD" di Vernon: valore oggetto o no?

Question

"Implementare DDD" di Vernon: valore oggetto o no?

#1 da (1 voti)

8

Nella pagina 382 di questo libro c'è un passaggio che parla dell'uso di oggetti valore negli aggregati, sotto la radice (entità). Esiste un esempio di Product che, oltre ad altri valori, contiene un Set<ProductBacklogItem> - raccolta di entità .

Ora, Vernon prova a spiegare perché ProductBacklogItem è un'entità e non un oggetto valore:

There are good reasons why ProductBacklogItem is modeled as an Entity rather than a Value. As discussed in Value Objects (6), since the backing database is used via Hibernate, it must model collections of Values as database entities. Reordering any one of the elements could cause a significant number, even all, of the ProductBacklogItem instances to be deleted and replaced. That would tend to cause significant overhead in the infrastructure. As an Entity, it allows the ordering attribute to be changed across any and all collection elements as often as a product owner requires. However, if we were to switch from using Hibernate with MySQL to a key-value store, we could easily change ProductBacklogItem to be a Value type instead. When using a key- value or document store, Aggregate instances are typically serialized as one value representation for storage.

Non capisco perché l'implementazione del repository determini se qualche modello sta per essere un'entità o un oggetto valore? Se andiamo all'archivio dei valori-chiave, potremmo avere ancora ordini di cui sta parlando.

Pensi che abbia senso?

domain-driven-design architecture

posta lawpert 31.10.2014 - 14:05

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design architecture

Perché Python e Ruby non fanno una distinzione tra dichiarare e assegnare un valore alle variabili? Riprova progettazione per volumi elevati

score 1 · Answer 1

Il motivo è che i database SQL memorizzano gli oggetti in modo relazionale: gli elementi sono archiviati in una tabella diversa rispetto alla radice aggregata e fanno riferimento all'aggregazione radice per ID. Quindi l'uso di MySQL richiede di modellare gli elementi come entità che vengono mantenute in una tabella separata dove ottengono l'id principale (con incremento automatico).

Nei negozi con valori-chiave es. MongoDB può memorizzare l'intera collezione di elementi come parte della radice aggregata. Gli elementi non diventerebbero entità separate (nella sua tabella) e quindi possono essere modellati come oggetti valore.

Eg. Il blog contiene commenti memorizzati come raccolta all'interno di:

{
  _id: 1,
  title: 'Some title',
  body: 'Blog body',
  comments: [{
     person: 'John Smith',
     comment: 'First comment of the blog',
     created_at: new Date()
  },
  {
     person: 'Peter Jackson',
     comment: 'Second comment of the blog',
     created_at: new Date()
  }],
}