Istanze multiple Istanze radice per transazione

Question

In DDD l'aggregato dovrebbe rappresentare il limite della transazione. Una transazione che richiede il coinvolgimento di più di un aggregato è spesso un segno che il modello dovrebbe essere perfezionato, o i requisiti transazionali dovrebbero essere rivisti, o entrambi.

Significa che il limite della transazione è per radice ISTANTA aggregata o per aggregato?

Dire che ho una radice aggregata chiamata "Nodo", all'interno di ogni "Nodo" ho una collezione di "Campi (oggetti valore)". Ogni "campo" è di tipo e può essere di tipo "nodo". Nel mio caso, se è di tipo "Nodo", memorizzerò l'ID sul root di aggregazione "Nodo".

Node (AggregateRootID 1) 
---> Field1 : String (John) 
---> Field2 : String (Doe) 
---> Field3 : Node (AggregateRootID 2) 

Node (AggregateRootID 2) 
--> Field1 : String (Jane) 
--> Field2 : String (Doe) 

Se si dispone di una transazione che aggiorna entrambe le istanze di Radice di aggregazione, è valida?

O significa che se ho aggregato "Nodo" e aggregato "Elemento" che non posso aggiornarli entrambi in una transazione?

Answer 1

Penso che un AR può essere più circa la consistenza confine oltre il confine transazioni.

Il fatto che una transazione avvenga si adatta perfettamente a un confine AR è solo una coincidenza.

Poiché le transazioni sono più di un problema a livello di applicazione, se si finisce con più di una AR in una transazione, allora non indica necessariamente un problema di progettazione.

In effetti, direi che in alcuni scenari di requisiti di coerenza al 100% potresti non avere nemmeno una scelta, ma includere tutte le modifiche in una transazione.

Answer 2

Supponiamo che tu stia lavorando con CQRS in un modello Async, quindi molto probabilmente i tuoi confini aggregati diventeranno l'unico aggregato modificato all'interno di quella transazione. Ora è completamente l'opposto se si utilizza CQRS in un modello di sincronizzazione o anche se si sta eseguendo lo stile di sviluppo RPC N-Tier, dove in una chiamata client vengono apportate poche modifiche al modello di dati dell'utente. In quest'ultimo caso, avrai sicuramente più istanze di aggregati all'interno della stessa transazione (es .: unità di lavoro con ambito di transazione).

Non penso che ci sia una risposta giusta o sbagliata alla tua domanda senza saperne di più sull'architettura del tuo sistema. DDD da solo non può impostare le regole per le transazioni del sistema. Quello che posso dire con certezza, è che se si utilizza un sistema basato su eventi asincrona con cqrs e capita di cambiare più di un aggregato per transazione, allora, e questa è solo la mia opinione, qualcosa non sembra essere destra.