Sourcing eventi e la generazione Leggi Modello

Question

Supponendo problema dominio Stack Overflow e la seguente definizione di eventi:

UserRegistered(UserId, Name, Email)
UserNameChanged(UserId, Name)
QuestionAsked(UserId, QuestionId, Title, Question)

Supponendo che il seguente stato di vendite evento (in ordine di apparizione):

1) UserRegistered(1, "John", "john@gmail.com")
2) UserNameChanged(1, "SuperJohn")
3) UserNameChanged(1, "John007")
4) QuestionAsked(1, 1, "Help!", "Please!")

Supponendo che il seguente modello di lettura denormalizzato per le domande sfogliare (per la prima pagina del SO):

QuestionItem(UserId, QuestionId, QuestionTitle, Question, UserName)

E il seguente gestore di eventi (che costruisce denormalizzato modello di lettura):

public class QuestionEventsHandler
{
    public void Handle(QuestionAsked question)
    {
        var item = new QuestionItem(
            question.UserId, 
            question.QuestionId, 
            question.Title, 
            question.Question, 
            ??? /* how should i get name of the user? */);
        ...
    }
}

La mia domanda è Come faccio a trovare il nome dell'utente , che ha fatto una domanda? O più comuni: come dovrei gestire gli eventi se il mio modello di lettura denormalizzato richiede dati aggiuntivi che non è esiste in particolare evento

?

Ho esaminato campioni di CQRS tra cui SimpleSQRS di Greg Young e Fohjin campione di Mark Nijhof. Ma mi sembra che siano funzionano solo con i dati che è incluso negli eventi.

Answer 1

Proprio arricchire l'evento con tutte le informazioni necessarie.

L'approccio di Greg, se ben ricordo, -. Arricchire l'evento durante la creazione e negozio / pubblicare in questo modo

Answer 2

Personalmente penso che ci sia nulla di sbagliato nel cercare il nome dell'utente all'interno del gestore di eventi. Ma se siete in una posizione dove non è possibile interrogare il nome dal modello di lettura per l'utente poi mi presento un gestore di eventi supplementare per QuestionEventsHandler, per gestire l'evento UserRegistered.

In questo modo il QuestionEventsHandler potrebbe mantenere il proprio repository di nomi utente (che non avrebbe bisogno di archiviare le email degli utenti). Il gestore QuestionAsked può quindi interrogare il nome dell'utente direttamente da un proprio repository (come ha detto Rinat Abdullin stoccaggio è a buon mercato!).

Oltre poiché la vostra QuestionItem leggere modello tiene il nome dell'utente, si avrebbe bisogno di gestire l'evento UserNameChanged all'interno del QuestionEventsHandler nonché per garantire il campo del nome all'interno del QuestionItem è up-to-date.

A me questo sembra meno sforzo di 'arricchire gli eventi' e ha il vantaggio di non le dipendenze edificio su altre parti del sistema e dei loro modelli di lettura.

Answer 3

eventi tirare dal EventStore.

Ricordate - I suoi modelli di lettura devono avere accesso in sola lettura al EventStore già. I modelli Leggi sono monouso. Sono semplicemente memorizzati nella cache di vista. Si dovrebbe essere in grado di cancellare / scadere tua lettura modelle in qualsiasi momento - e automaticamente ricostruire i ReadModels dal EventStore. Così -. Vostri ReadModelBuilders devono già essere in grado di query per eventi passati

public class QuestionEventsHandler
{
    public void Handle(QuestionAsked question)
    {
        // Get Name of User
        var nameChangedEvent = eventRepository.GetLastEventByAggregateId<UserNameChanged>(question.UserId);

        var item = new QuestionItem(
            question.UserId, 
            question.QuestionId, 
            question.Title, 
            question.Question, 

            nameChangedEvent.Name
    }
}

Anche rendersi conto - la necessità repository EventStore non essere il vero EventStore, anche se sicuramente potrebbe essere. Il vantaggio dei sistemi distribuiti è che si può facilmente replicare l'EventStore, se necessario, più vicini ai vostri ReadModels.

ho incontrato questo esattamente lo stesso scenario ... dove avevo bisogno di più dati di quelli era disponibile in un singolo evento. Ciò è particolarmente vero per gli eventi Create-tipo, che richiedono che popolano un nuovo ReadModel con stato iniziale.

Da Leggi Models: Si potrebbe tirare da altri modelli Continua. Ma io davvero non consiglio questo, come ci si introdurrà una grande palla di fango dipendenza dove viste dipendono vista dipendere da vista.

Ulteriori dati in Eventi: Davvero non si vuole gonfiare i vostri eventi con tutti i dati in più di cui ha bisogno per le viste. Sarà davvero male quando le modifiche a dominio e sarà necessario trasferire gli eventi. Dominio eventi hanno scopi specifici - che rappresentano i cambiamenti di stato. Non visualizzare i dati.

Spero che questo aiuti -

Ryan