Possiamo usare insieme REST + Event Sourcing + CQRS

Question

Comprendo le basi di REST + Event Sourcing. Non ho mai lavorato su un'API RESTful rigorosa e non su alcun progetto Event Sourcing.

Qualcuno può spiegare se entrambi possono essere utilizzati insieme?

Come nel caso del sourcing di eventi, il client invia eventi, vuol dire che sul server c'è una singola raccolta di eventi e tutti i POST dell'API si troveranno su quella raccolta, per aggiungere eventi ad esso?

Come può il client scoprire i comandi che può inviare al server?

Answer 1

Risposta breve - sì, possiamo.

Tutte le cose che si stanno enumerando, voglio dire REST, ES e CQRS sono per scopi diversi. Quindi non vedo alcun problema per afferrare tutto insieme.

Guarda: REST è un modo per fare un'API di servizi Web, ES è uno strumento per comunicare all'interno di un dominio e CQRS come un'architettura di medio livello.

Bene, in ES il client (se si parla di un client Web) non invia eventi di dominio. Se intendi un altro BC e BC è una parte del tuo dominio, suppongo che un evento di trasporto debba essere risolto in un altro modo, un bus di servizio o qualcosa del genere sarebbe fantastico. Se un BC non fa parte del tuo dominio, devi comunicarlo tramite ACL e API, non con eventi di dominio raw. :)

Breve sui comandi. Di nuovo, nel CQRS un comando vive all'interno di un limite dell'applicazione. I client esterni (client Web, API-client) non dovrebbero avere la capacità di inviare comandi dell'applicazione direttamente. È necessario fornire un'API (client interno) che consenta di eseguire alcuni casi d'uso del servizio ma non comandi singoli e separati. Per un esempio fatto da sé puoi provare ad ottenere una risposta su una domanda molto popolare di SO - come controllare username uniques quando usiamo CQRS? :)

Answer 2

Qualcuno può spiegare se entrambi possono essere utilizzati insieme?

Sì. Il client (browser) fa semplicemente ciò che vuole e il server (http) può registrare tali azioni come eventi.

Come nel caso del sourcing di eventi, il client invia eventi, significa che sul server c'è una singola raccolta di eventi e tutti i POST dell'API si troveranno su quella raccolta, per aggiungere eventi ad esso?

No. Il client può essere il creatore di eventi, ma non deve sapere cosa costituisce un evento al fine di evitare un accoppiamento stretto tra il server e il client in base a tale raccolta di eventi. Event Sourcing dovrebbe essere incapsulato ed è nascosto all'attore.

Come può il client scoprire i comandi che può inviare al server?

Questo non è necessario se non è necessario inviare eventi sulla stessa raccolta come suggerito nella domanda precedente. È possibile pubblicare semplicemente un'API REST nel modo desiderato e nascondere l'origine degli eventi dal client/attore. Dai uno sguardo a http://restdesc.org/.

Answer 3

REST è un metodo di consegna che determina l'interfaccia dell'applicazione.Si utilizza REST principalmente con il modello di consistenza immediata, ma può supportare un modello di coerenza finale rispondendo ai comandi accettati.

L'origine degli eventi è un meccanismo di memorizzazione dei dati generale. Si utilizza solitamente il sourcing di eventi con un modello di coerenza finale insieme alla progettazione basata sul dominio e la segregazione di comandi e query, ma può supportare un modello di coerenza immediato, probabilmente con un commit a più fasi.

Essi risolvono cose completamente diverse nella vostra applicazione e sono compatibili tra loro, quindi è possibile utilizzarle insieme.

Come nel sourcing evento, il cliente inviare eventi, questo significa che sul il server v'è un unico insieme di eventi e di tutti i messaggi del API sarà in tale raccolta, di aggiungere eventi ad esso?

Hai completamente frainteso il concetto. È possibile memorizzare una sequenza di eventi in una memoria eventi. Gli eventi sono cambiamenti di stato, quindi se memorizzi ogni cambio di stato della tua applicazione e la rigiochi nell'ordine corretto, puoi ricreare lo stato attuale della tua applicazione. Questo è molto buono, perché è possibile migrare i dati in un altro database semplicemente riproducendo gli eventi e trasformandoli in query di database. Puoi fare lo stesso per creare una cache di query usando un normale database. Quindi i tuoi clienti possono leggere quella cache delle query invece di ricreare sempre lo stato attuale dai motivi.

Gli eventi in genere non vengono creati dal client. Con la progettazione basata sul dominio, la logica del dominio crea eventi di dominio elaborando i comandi.

Come può il client scoprire i comandi che può inviare al server?

Tramite REST i client utilizzano i collegamenti per inviare richieste al servizio REST. Il servizio REST può elaborare quelle richieste e trasformarle in comandi e query. I comandi vengono elaborati dalla logica del dominio e generano eventi di dominio. Le query vengono trasformate in query di database che indirizzano le cache di query.