DDD - Stesso ID / Chiave primaria, classe di Aggragate Root diversa per Contesto Limitato

Question

DDD - Stesso ID / Chiave primaria, classe di Aggragate Root diversa per Contesto Limitato

#1 da (1 voti)

0

Sto lavorando per capire DDD e voglio vedere se questa idea è valida, se è una pratica comune e se ci sono insidie o complicazioni impreviste.

Voglio avere effettivamente una "entità" con una chiave primaria globalmente unica. Voglio usare il sourcing di eventi. Vorrei che diverse classi AR rappresentassero questa "entità" a seconda del contesto.

Ad esempio, in un sito di e-commerce avrei diversi tipi di pagine (pagine di contenuto statico, pagine di categorie, pagine di prodotto). Avrei anche dei prodotti. Dovrebbe esserci una mappatura 1: 1 tra un prodotto e una pagina prodotto, in effetti un sottotipo ProductPage di Page con un unico ID univoco che rappresenta sia la pagina che i componenti del prodotto.

Quando nel contesto della gestione dei contenuti, caricherò tutti gli eventi Page per quell'ID per ricostruire il mio oggetto Page AR, fare qualsiasi azione Page correlata e salvare gli eventi Page appropriati (ex . %codice%).

Quando nel contesto della gestione del prodotto, caricherò tutti gli eventi Page.EditContent() per quell'ID per ricostruire l'oggetto Product AR, fare qualsiasi azione Product relativa e salvare gli eventi Product appropriati ( ex. Product ).

Quindi, quando generi il mio modello di lettura, caricarei tutti gli eventi per quell'ID per costruire un Product.SetPrice() e salvarlo nel database del modello letto.

Questo è un modo corretto di fare questo o è una cattiva idea per qualche motivo che non riesco a vedere? O c'è un modo migliore?

domain-driven-design cqrs event-sourcing read-model

posta Entith 09.11.2017 - 17:19

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design cqrs event-sourcing read-model

Come scalare l'ambiente degli sviluppatori? Trattare con la ridondanza dei dati immagine in una tabella NoSQL

score 1 · Accepted Answer

Recentemente ho risposto a una domanda diversa con una risposta simile qui:

È possibile aggregare il riferimento di root un'altra un'altra radice?

Penso che ti stai avvicinando perfettamente al tuo problema.

Penso che mappare le radici e le entità aggregate a classi diverse adatte a ciascun contesto sia un approccio sicuro ed estendibile. Ogni volta che nuovi ragazzi si uniscono al team, non devono preoccuparsi di rompere qualcosa nel sistema. Possono mappare una nuova radice aggregata e creare una funzione come se stessero costruendo un'app separata.

Questo comporta l'ovvio costo di molto più codice e la falsa percezione che il codice venga duplicato. In passato ho sperimentato con una singola classe 'Utente' per rappresentare gli utenti in tutti i contesti (login, mailing, gestione degli investimenti, ecc.). Ora sono diverse migliaia di problemi di linea che non vogliono toccare nessuno.

Per il lato di lettura del sistema utilizziamo un ORM diverso tutti insieme. Uno adatto per operazioni veloci, di sola lettura senza capacità di tracciamento dello stato. Questi si richiamano da molte fonti diverse nell'archivio dati e si associano a modelli piatti che sono di sola lettura e non offrono alcuna logica. Per lo più questo si traduce in una query e un modello per caso d'uso, che abbiamo trovato è facile da mantenere poiché i contesti diversi raramente richiedono gli stessi identici dati. Evitiamo di caricare più AR e quindi di mapparli da quelli a un modello di vista. Questo processo è più costoso di quello che deve essere.

Ovviamente ci sono eccezioni a qualsiasi regola. Se hai un'entità semplice e solo 1 o 2 contesti prevedibili con una sovrapposizione del 90%, mappalo a un'entità. Puoi sempre dividerlo in un secondo momento.

Questa è solo la mia esperienza con DDD su alcune delle cose su cui ho lavorato. Potrebbe non essere applicabile in tutte le situazioni, ma sembra che tu sappia cosa stai facendo.