DDD, Saga ed event-sourcing: un'Azione compensativa può essere semplicemente un'eliminazione nell'archivio eventi?

Non dovresti eliminare gli eventi dal tuo negozio di eventi. Questi rappresentano qualcosa che è successo. Se succede qualcosa ora, dovresti saperlo anche tu, quindi aggiungi un evento che costringerà il tuo aggregato a tornare ad uno stato precedente. È un peccato cancellare le informazioni dal tuo database.

pensa all'esempio del carrello di greg young e degli articoli rimossi. Forse domani le informazioni sull'azione compensativa potrebbero essere di qualsiasi valore ..

Per quanto riguarda la saga, ogni cosa è corretta, per quanto mi conosco. Dovresti pensare alla saga come a una macchina statale. Lo fa solo.

È un comando che la saga sta emettendo per dire all'aggregato di fare qualcosa. Di questa azione ci sarà un evento. Questo evento potrebbe essere l'azione correttiva di cui hai bisogno, o potrebbe essere necessario denormalizzarlo in una vista in modo che alcuni utenti lo vedano per decidere cosa fare.

Dipende dalle tue regole aziendali. O c'è una soluzione semplice: la radice aggregata sa che in tal caso lo fai, o la scelta è troppo complessa per essere programmata (i costi di sviluppo sono troppo alti) e quindi potresti proporlo a qualche utente, che potrebbe scegliere tra diverse azioni. Tutto dipende dal contesto dell'azione compensatrice. Questa è pura regola aziendale. Cosa dovremmo fare in questo caso o in quel caso. Questo è qualcosa da chiedere al tuo esperto di dominio, e quindi scegliere con lui, se è meglio sviluppare una soluzione automatica o se la soluzione è chiedere all'utente Ronald R., perché è lui a rispondere di solito a questa domanda.

Per completezza ho pensato di includere uno snippet pertinente di Martin Fowler sui modi per ripristinare lo stato:

As well as events playing themselves forwards, it's also often useful for them to be able to reverse themselves.

Reversal is the most straightforward when the event is cast in the form of a difference. An example of this would be "add $10 to Martin's account" as opposed to "set Martin's account to $110". In the former case I can reverse by just subtracting $10, but in the latter case I don't have enough information to recreate the past value of the account.

If the input events don't follow the difference approach, then the event should ensure it stores everything needed for reversal during processing. You can do this by storing the previous values on any value that is changed, or by calculating and storing differences on the event.

Da: link

Concettualmente:

• L'evento è qualcosa che è successo. Il passato non può essere cambiato.
• Il comando è qualcosa da fare. Il comando potrebbe non accadere (può essere rifiutato).

Possiamo modificare il nostro stato futuro solo eseguendo un altro comando (Compensate Action) che dovrebbe comportare lo stato di modifica degli eventi dell'applicazione.

Per "confondere" la domanda, pensa a questa frase "cancella l'ultimo evento":

• Cosa succede se l'ultimo evento non è quello che deve essere eliminato? Cosa accadrebbe se altri eventi accadessero dopo quello da cancellare? Anche questi eventi devono essere modificati (dato che il loro stato base sarebbe cambiato eliminando l'evento prima di loro).
• Cosa succede se l'evento è stato inviato al sistema esterno? Potresti non avere accesso per correggere il suo stato se non l'invio di un altro evento.

In breve, non hai alcuna opzione per eliminare gli eventi all'interno del pattern CQRS.

Potresti ridurre il tuo Event Store creando uno stato di istantanea (basato su tutti gli eventi che portano a quello stato), ma questo aspetto fisico non ha nulla a che fare con il concetto di evento.

Geert-Jan, anch'io penso che l'azione di compensazione possa semplicemente cancellare gli eventi corrispondenti. Ha senso e mostra un altro vantaggio del modello di progettazione di Event Sourcing: implementazione più semplice del modello di progettazione di Transazione compensativa.

Alcuni dicono che l'eliminazione dell'evento viola i "principi" del sourcing di eventi o CQRS. Penso che sia una generalizzazione limitante. Penso che sia corretto cancellare un evento se è stato creato nell'ambito di una transazione globale che viene annullata. Considera lo pseudocodice:

try {
    newEvents = processMycommand(myCommand)
    for (Event newEvent : newEvents)
        EventStore.insertEvent(newEvent);
} catch (Exception e) {
    EventStore.rollback();
}

Supponiamo che il tuo archivio eventi sia un database transazionale. Nello pseudocodice, è possibile immaginare la situazione in cui è stato inserito il primo evento, ma quando si è tentato di inserire il secondo evento è stata generata un'eccezione. Il comando rollback ripristinerebbe naturalmente l'inserimento del primo evento. È ragionevole?

Se è ragionevole per una transazione di database ACID (transazione con commit / rollback), perché non sarebbe ragionevole per una transazione di compensazione?

Quando si esegue la transazione Saga globale, le modifiche ai dati possono essere annullate (mediante compensazione). Non è necessario mantenere l'evento creato durante la transazione perché la transazione non è stata completata.

Ora, se la compensazione tenta di eliminare un evento e quell'evento non è il più recente evento su un oggetto, la cancellazione non dovrebbe verificarsi. Ma in generale, è improbabile che ciò accada, specialmente nelle soluzioni ad alta intensità di lettura.