Dove memorizzare "Who" e "When" di un comando e / o evento?

Question

Dove memorizzare "Who" e "When" di un comando e / o evento?

#1 da (2 voti)

4

Gran parte dei vantaggi di Event Sourcing si applicano alla capacità di controllare il sistema e mostrare lo stato di un aggregato per tutta la sua durata. Tuttavia, non sono stato in grado di trovare esempi su dove registrare chi ha emesso il comando e quando è stato emesso.

Ho fatto molto del mio apprendimento suddividendo il viaggio CQRS su MSDN. L'unico posto in cui vedo l'indicazione di chi ha creato qualcosa è nella classe ConferenceEvent .

public abstract class ConferenceEvent : IEvent
{
    public Guid SourceId { get; set; }

    // **snip**

    public Owner Owner { get; set; }
}

Non riesco a trovare alcuna indicazione che quando si verifica l'evento è mai registrato. Ogni Command deve avere CreatedOn e CreatedBy che poi viene propagato a Event . Quindi, quando reidratate l'aggregato, che verrebbe ereditato dall'esempio seguente, gli eventi saprebbero quali campi chi e quando compilare?

public abstract class EventSourced : IEventSourced
{
    [Required]
    public string CreatedBy { get; set; }
    public DateTime CreatedOn { get; set; }
    public string LastModifiedBy { get; set; }
    public DateTime? LastModifiedOn { get; set; }
    public string DeletedOn { get; set; }
    public DateTime? DeletedBy { get; set; }
}

Ogni evento sembra essere intuitivamente perché mentre contiene le informazioni per cosa e dove ; ma per gli altri due di dubya?

c# cqrs event-sourcing audit

posta drovani 09.12.2016 - 23:27

fonte

1 risposta

Leggi altre domande sui tag c# cqrs event-sourcing audit

Propagazione dello stato (dal basso verso l'alto) nell'albero a più passi Wrapping Controller / ApiController per rimuovere i boilerplates

score 2 · Accepted Answer

Where to store the “Who” and “When” of a Command and/or Event?

Come forse stai suggerendo, memorizza chi e quando è presente nell'Event Store, proprio insieme all'evento (cosa). Infatti, chi e quando sono parti integranti dell'evento comando.

Then, when rehydrating the aggregate, which would be inherited from the sample below, the events would know which who and when fields to populate?

Non è necessariamente richiesto che gli aggregati mantengano tutti quei campi; ciò è richiesto solo se il tuo dominio (e quindi il modello di dominio) ne ha bisogno.

Gli eventi stessi, che servono per l'audit (oltre a riprodurre secondo necessità per ricostruire il modello di scrittura) contengono il chi e quando.

Che chi e quando viene utilizzato insieme al comando in ogni evento dalla logica aziendale per far avanzare lo stato degli aggregati.

Tuttavia, l'aggregato non deve necessariamente conservare creato e modificato da ultimo, a meno che il dominio non ne abbia bisogno.

Un controllo completo dovrebbe necessariamente esaminare l'intera sequenza di eventi direttamente dall'Event Store, piuttosto che basarsi solo, ad esempio, sull'ultima modifica di un aggregato; ciò significa che l'aggregato non deve memorizzare quei campi specificamente per l'audit e quindi non deve necessariamente memorizzare le ultime informazioni modificate nel modello di scrittura a meno che non sia altrimenti richiesto dal modello di dominio.

... the events would know which who and when fields to populate?

Gli eventi non "sanno"; sono oggetti immutabili abbastanza semplici accettati nell'Event Store solo per append.

Piuttosto è la logica aziendale nel modello di dominio che comprende come riprodurre eventi nel modello di scrittura corrente di CQRS; ovvero, in che modo gli aggregati (il cui stato ultimo / corrente è memorizzato nel modello di scrittura) vengono aggiornati in risposta a eventi contenenti comandi di modifica (cosa), con riferimenti a vari aggregati (dove, in un certo senso) e con identità dell'autore ( chi ha richiesto) e i tempi (quando richiesto).

Il motivo per cui il client ha richiesto il comando change, che è stato accettato dal sistema come evento e archiviato nell'archivio eventi. (Potremmo chiedere al meta perché il cliente ha voluto farlo, ma è più profondo di CQRS + ES può andare!)