CQRS di Sourcing di eventi e richiesta di eventi che terminano su Richiesto

Question

CQRS di Sourcing di eventi e richiesta di eventi che terminano su Richiesto

#1 da (2 voti)
#2 da (1 voti)

2

In ES / CQRS, possiamo / possiamo trattare le richieste come eventi?

Considera il seguente flusso

Un ospite ha visitato alcuni URL e ha pubblicato dati per creare un nuovo account. Ecco un modo per implementarlo

1- Invoke CreateNewUserCommand [payload = posted data]

2- Invoke CreateUserHandler(CreateNewUserCommand)

3- Fire CreateNewUserRequestedEvent [payload= posted data]

4a- Handle it in CreateNewUserEventHandler

4b- Validate the input against invariants 

5- If validation failed [invalid email, duplicate user, payment not sufficient etc] fire another event
UserCreationFailed:PaymentInsufficent [paylod= posted data]
UserCreationFailed:EmailInvalid [paylod= posted data]
UserCreationFailed:UserAlreadyExists [paylod= posted data]

6- If validation is successfull
fire an event
NewUserCtreated [payload= posted data + created user id]

Martin Fowler afferma chiaramente che proteggiamo gli eventi del dominio quando lo stato è cambiato. Ora se consideriamo CreateNewUserRequestedEvent, è solo un'intenzione di cambiare lo stato.

Successivamente, quando ripetiamo gli eventi, CreateNewUserRequestedEvent non conta come un evento per partecipare all'aggiornamento di stato, ma fa l'evento NewUserCtreated.

Tuttavia, se guardiamo esternamente il sistema, anche una richiesta di fare qualcosa [CreateNewUserRequestedEvent] è un evento. Prendi l'esempio di un caso d'uso quando abbiamo fatto la richiesta, la richiesta è stata salvata, ma il server va giù in quel momento.

La prossima volta che il server sale, possiamo riprendere da dove siamo partiti e continuare a creare l'utente.

cqrs event-sourcing

posta Waku-2 28.08.2018 - 05:20

fonte

2 risposte

1

In ES/CQRS, do/can we treat requests as events?

Puoi.

Di solito ciò significa che la decisione di persistere nell'evento non avrà alcuna logica di dominio ad essa associata. Il server aggiunge le informazioni a un flusso qualunque sia la posizione corrente.

Gli sviluppatori di LMAX hanno pubblicato un sacco di lavoro descrivendo la libreria dei disruptori ; se osservi attentamente come lo usano, vedrai che un caso comune per loro è che gli input sono stati immediatamente (e sequenzialmente) scritti in un diario, mentre hot standbys usavano le repliche di quelle riviste per assicurarsi che si trovassero nello stesso stato .

Potresti anche voler esaminare ... un'opinione di un apostata , dove Pat Helland parla di entità (utilizzando una definizione un po 'diversa dalla solita ortografia DDD / CQRS / ES) e in che modo tengono traccia delle informazioni che sono state condivise con loro.

risposta data 28.08.2018 - 15:40

fonte

Leggi altre domande sui tag cqrs event-sourcing

L'importazione di caratteri jolly è una cattiva idea? Come ridurre le possibilità di ottenere conflitti di merge che si verificano in due progetti della stessa base di codice clonato

score 2 · Accepted Answer

In CQRS + ES ci sono eventi di dominio che rappresentano fatti che vengono mantenuti al posto dello stato piatto e comandi che esprimono l'intenzione di fare qualcosa che risulterà in zero o più fatti. Detto questo, c'è una differenza tra eventi di dominio, comandi e messaggi di infrastruttura (come il tuo "RequestEvent") in un'architettura basata su messaggi / eventi: eventi / comandi di dominio sono strongmente correlati alla lingua ubiquitaria, al dominio e ai messaggi infrastrutturali non lo sono, portano solo informazioni di basso livello.

I messaggi dell'infrastruttura possono essere la base per un messaggio piacevole e resiliente basato su un'architettura asincrona di basso livello, come quella che stai descrivendo, che aggiunge resilienza all'applicazione.

Tuttavia dovresti trattare diversamente gli eventi / comandi di dominio e i messaggi dell'infrastruttura, cioè inserirli in moduli / spazi dei nomi diversi, nominarli diversamente o almeno conoscere la differenza tra loro.