NoSQL & DDD: Va bene avere due classi di modelli per la stessa entità b / ce l'ho parzialmente duplicata in DB?

Naviga le tue risposte
4

Ho un DB NoSQL con parti dei miei dati denormalizzati e duplicati. Per concretezza, diciamo che ho:

  1. Un set di documenti chiamato "persone" contenente le specifiche complete delle persone.
  2. Un set di documenti chiamato "voti" contenente i risultati dei round di votazione in una determinata organizzazione. Ogni documento di voto contiene un elenco di persone che hanno votato a favore e contro. Gli elementi di tale elenco contengono un sottoinsieme di dati rispetto a ciò che è memorizzato in un documento "persone".

È in conformità o contro i principi del DDD avere due classi modello separate nella mia app, ciascuna rappresentante una persona - una con le specifiche complete (interrogate da "persone"), una con il sottoinsieme di dati (interrogati da "voti" ")? Per esempio. Person e VotingPerson .

Mi sembra che una tale soluzione rientri nella portata dell'idea del "contesto limitato", quindi va bene, ma voglio essere sicuro.

Grazie!

    
posta Jan Żankowski 09.10.2017 - 14:11
fonte

2 risposte

3

Dalla vista punto DDD, le persone di solito prestano meno attenzione al particolare archivio persistente, invece si concentrano sulla lucidatura dei modelli di dominio. Dopo tutto, la persistenza è solo una questione di infrastruttura o di dettaglio dell'implementazione.

È inoltre del tutto perfetto che due modelli di dominio rappresentino la stessa cosa fisica. Nell'esempio del libro IDDD di Vaughn Vernon, utilizza BacklogItem e ProductBacklogItem nel contesto limitato projectPM. In questo caso, ha modellato l'elemento del backlog in due modi diversi quando appartengono (o meno) al prodotto.

È anche molto comune avere rappresentazioni diverse oltre i confini. Sempre in IDDD, Vaughn Vernon utilizza Porte e amp; Schede disponibili per translate utente e ruolo nei limiti di identità e accesso a un gruppo di collaboratori .

    
risposta data 10.10.2017 - 01:57
fonte
1

Per questo, dovresti vedere i tuoi requirments.

Tecnicamente, poiché gli archivi NoSQL potrebbero richiedere la duplicazione di alcuni dati, va bene. Ma non penso che sia correlato a Domain Driver-Design, DDD è decisamente superiore a tali problemi.

Ora quali sono i requisiti specifici sulla funzionalità dei tuoi voti?

  1. Memorizza da qualche parte chi vota in modo che non possano votare due volte?
  2. Essere in grado di consultare chi ha votato cosa?
  3. Altri requirments? Quali dati sarebbero necessari dalle persone? o dai sistemi che interagiscono tra loro o nell'interfaccia utente.

Nel caso di uno, mantenere un identificatore univoco non modificabile delle "Persone" è sufficiente. Al secondo:

  • È possibile eseguire una sorta di JOIN tra l'identificativo univoco e gli archivi "Persone", tuttavia questo può essere abbastanza scomodo per il tuo negozio NoSQL, alcuni supportano che, alcuni non lo fanno e potrebbe verificarsi abbastanza penalità per farlo manualmente.
  • Potrebbe essere necessario aggiungere per esempio il nome e il cognome e nell'interfaccia utente si avrà un collegamento con il testo "Nome Cognome". Il link potrebbe aprire una nuova finestra per le informazioni sulle persone classiche recuperate dallo store "Persone". Tuttavia, tieni presente che se i dati relativi al nome e al cognome sono modificabili, dovrai aggiornarlo anche qui, quando accadrà.

Alla fine i tuoi requirments specificheranno qualcosa come:

There is one detailed view of People, all others page that shows people should only show their last name and first name and a link redirecting to the detailed view.

    
risposta data 09.10.2017 - 16:20
fonte

Leggi altre domande sui tag

Progettazione di una funzione multi-test per convalidare una stringa Come funziona il Base Address Registers (BAR) in una scheda PCI?