Later the event responder would detect out of order events and merge them.
Possibile, ma non sto vedendo molto di questo nella mia ricerca.
Gli oggetti di origine evento non si iscrivono agli eventi, per quanto osservino flussi di eventi.
Ad esempio, un tipico idioma di reidratazione è che il componente di persistenza recupererà gli eventi dall'archivio eventi e li assemblerà in un flusso, prima che un repository acquisisca il flusso, reidratizzi l'entità di origine evento e offra tale entità al componente dell'applicazione pronto per l'uso.
Dopo aver reidratato l'entità, possiamo proporvi una modifica, raccogliere gli eventi che rappresentano tale modifica e quindi proporre che l'archivio eventi aggiunga questi nuovi eventi allo stream. La garanzia fornita dall'archivio eventi è che, se gli eventi vengono accettati, sarai in grado di recuperare la nuova versione dello stream con gli eventi nell'ordine corretto.
Il solito modo di supportare questo requisito è che gli eventi siano abbinati a un numero di sequenza, che può essere usato per ordinarli all'interno del flusso.
Puoi pensare che questi numeri di sequenza siano id versione, ma probabilmente dovresti tenere presente che sono versioni dello stream, non versioni dell'entità rappresentate dallo stream - non tutti gli stream di eventi sono associati a un dominio oggetto (pensa eventi utente vs eventi dominio o proiezioni che uniscono eventi da più flussi).
Se stai cercando di accoppiare il sourcing di eventi con pub / sub, probabilmente avrai un driver responsabile della ricostruzione dei flussi. E va bene, immagino - in pratica stai creando una facciata in modo che l'abbonamento abbia l'aspetto di un negozio di eventi. Ma tieni presente che solo gli eventi passati vengono pubblicati nel negozio degli eventi; se stai caricando un'entità in modo che tu possa cambiarla, dovrai comunque aggiungere la cronologia delle versioni più recente, quindi stai davvero guadagnando molto provando a ricostruire il flusso localmente? Probabilmente è più facile chiedere all'archivio degli eventi di aggiornarti.
I progetti / query sono il caso dell'angolo dispari: ti interessa il contenuto dello stream, ma non intendi aggiungerlo allo stream. In particolare, è generalmente OK se si è "indietro" in tempo. Lì, gli stream forniti dal driver sottoscritto sono abbastanza recenti da pubblicare una nuova proiezione.
Pub / Sub può ancora essere un modo utile per consumare eventi quando non è necessario il sourcing diretto degli eventi. Un tipico caso d'uso qui potrebbe essere un gestore di processi: un evento appare nella nostra sottoscrizione e determina che vogliamo avviare una nuova istanza di gestore di processo. Quindi il gestore di eventi pianificherà un'attività per caricare una nuova istanza di quel gestore. Il process manager, essendo esso stesso di origine evento, avrà bisogno di accedere al proprio stream per recuperare il proprio stato; ma l'invio dell'evento che deve essere gestito dal gestore dei processi non ha bisogno di sorgenti di eventi e può essere eseguito direttamente dall'abbonamento, nessun driver richiesto.