Aggiornamento di più aggregati utilizzando JOliver EventStore

Question

Ho una domanda riguardante gli aggiornamenti di più aggregati in una singola transazione utilizzando JOliver's Event Store. Come ho capito, ogni aggregato dovrebbe avere il proprio flusso di eventi. Ora, mentre molti gestori di comandi caricano solo un singolo aggregato e aggiornano solo quell'aggregato (ad esempio, salvano gli eventi per tali aggregati), posso immaginare che ci saranno gestori di comandi che devono aggiornare più aggregati. E, naturalmente, mi piacerebbe farlo in modo transazionale.

Tuttavia, non vedo come potrei farlo con l'Event Store. La memorizzazione degli eventi viene effettuata chiamando lo CommitChanges() su un flusso di eventi. Se stiamo aggiornando più aggregati, avremo più stream di eventi e quindi più chiamate a CommitChanges(). L'unico modo per renderlo transazionale è quello di racchiuderlo in un TransactionScope, ma ciò non ha molto senso, poiché la tecnologia di archiviazione sottostante potrebbe non supportare le transazioni. Così io alla fine con questo codice, che è sicuramente non è quello che sto cercando:

 Guid aggregateGuid1 = Guid.NewGuid(); 
     Guid aggregateGuid2 = Guid.NewGuid(); 
     Guid commitGuid = Guid.NewGuid(); 

     var stream = store.OpenStream(aggregateGuid1, 0, int.MaxValue); 
     stream.Add(new EventMessage() { Body = new MonitorDisabled { MonitorGuid = aggregateGuid1, User = "A" } }); 
     stream.CommitChanges(commitGuid); 

     stream = store.OpenStream(aggregateGuid2, 0, int.MaxValue); 
     stream.Add(new EventMessage() { Body = new MonitorEnabled { MonitorGuid = aggregateGuid2, User = "B" } }); 
     // Can't commit twice with the same commit id, what if fails after first one? No way for the store to know it had to write the second part of the commit. 
     stream.CommitChanges(commitGuid); 

Questo mi fa sentire che sono qualcosa di completamente mancante su come deve essere utilizzato l'evento di archivio. Qualcuno potrebbe aiutarmi qui? Molte grazie!

Answer 1

Non posso parlare per John Oliver, ma penso che la risposta sia "non farlo". Gli aggregati sono confini delle transazioni. Se è necessario coordinare il commit di più aggregati, è necessario un processo di coordinamento esplicito, come una saga, che esegua e, se necessario, annulla gli eventi pertinenti.

Answer 2

Un aggregato definisce un limite di transazione.

Se è necessario eseguire transazioni tra aggregati, è necessario rivedere i propri aggregati e, eventualmente, riprogettarli.

Nei casi in cui un'operazione (comando) interessa più di un aggregato e si è sicuri che i propri aggregati siano ben progettati e mappati ai limiti di consistenza reali nel proprio dominio, eventual consitency potrebbe essere quello che si sta cercando. Basta inviare un comando a ciascun aggregato e avere due transazioni, una per ciascuna di esse. Se non ritieni che la coerenza finale sia giusta per il tuo caso, temo che sia di nuovo al tavolo da disegno.

Answer 3

A volte può essere più facile sfruttare le transazioni distribuite in questi scenari se l'infrastruttura li supporta.

TransactionScope con EventStore:

L'EventStore di default sopprime qualsiasi transazione di ambiente creato da NServiceBus prima di commettere le modifiche al database. Tuttavia se si utilizza una coda e un database che supporta le transazioni distribuite (MSMQ, SQL Server, Raven ecc.), È possibile modificare il TransactionScopeOption di EventStore su Obbligatorio. Ciò assicurerà che l'EventStore presenti nella transazione ambientale, di cui verrà distribuito utilizzando MSDTC e la coda di messaggi e il database verranno mantenuti sincronizzati. - NES Documentation

transazioni di documenti trasversali con RavenDB:

Potrai estrae le transazioni dai miei morti, mani fredde e spezzate - Ayende