Terza puntata all’insegna delle architetture event-driven: oggi scopriamo la differenza tra i diversi oggetti che concorrono all’interno di questo dominio, e quali sono alcuni esempi.

Tipologia di eventi

Eventi e non-eventi

Vista l’importanza relativa al concetto di evento, è importante definire anche cosa non sia un evento.

• Acquisto di un servizio X da parte di un utente Y è un evento, Aggiornamento dello stato della transazione X da - “Da Pagare” a “Pagata” non lo è, in quanto rappresenta un cambiamento di dato, e non un evento significativo per il sistema.
• Giacenza oggetto X modificata è un evento, Aggiunto N alla capienza di magazzino dell’oggetto X non lo è.
• Utente registrato correttamente è un evento, Creazione di un nuovo utente non lo è.

Questi sono solo alcuni esempi, ma è importante capire la differenza tra un evento di sistema e un cambiamento di dati, in quanto il primo è significativo per il business, mentre il secondo è significativo solo per il sistema che lo ha generato.

Eventi e comandi

Spesso, quando si parla di EDA, agli eventi è affiancato il concetto di comando (command). Un comando è un’informazione che viene inviata a un sistema per richiedere l’esecuzione di un’azione. Un esempio di comando è Genera fattura per la transazione X, che viene inviato al sistema per richiedere la generazione di una fattura.

Viene da sé che i comportamenti sono agli antipodi: un evento documenta un cambiamento di stato avvenuto nel sistema, mentre un comando richiede al sistema di eseguire un’azione.

Esempio di comando, dove l’ownership è del consumer

Esempio di evento, dove l’ownership è del producer

Spesso i comandi vengono utilizzati nel pattern CQRS, che è un pattern di progettazione che prevede la separazione tra la parte di lettura e la parte di scrittura di un sistema. In questo caso, i comandi vengono utilizzati per richiedere la modifica di un dato, mentre gli eventi vengono utilizzati per documentare il cambiamento di stato avvenuto nel sistema.

Eventi e messaggi

Anche in questo caso, parliamo di una evoluzione del concetto di evento. Un messaggio, a differenza di un evento, sa esattamente dove deve essere inviato, mentre un evento no. Un evento viene inviato su un canale, e chiunque sia interessato a quel tipo di evento può sottoscriversi a quel canale per riceverlo (ad esempio, in broadcast), mentre un messaggio viene inviato a uno o più destinatari specifici. In questo caso parliamo, quindi, di un modello di comunicazione one-to-one.

Anche da un punto di vista di terminologia, infatti, si differenzia il concetto di emettere un evento da quello di inviare un messaggio.

Come vengono gestiti un messaggio e un evento - Credits to serverlessland.com

Eventi e query

Un’altra evoluzione del concetto di evento è la query. Una query è un evento che viene inviato a un sistema per richiedere un dato. Un esempio di query è Restituisci la lista degli utenti registrati, che viene inviata al sistema per richiedere un output.

Questa è da molti ritenuta una forzatura del concetto di evento, in quanto per sua stessa natura un evento dovrebbe essere asincrono, mentre una query è paragonabile a un processo sincrono, in quanto per procedere nell’esecuzione del processo è necessario attendere e ascoltare la risposta (reply) del sistema.

Anche la query fa parte del pattern CQRS. In questo caso, la query viene inviata alla parte di lettura del sistema, che restituisce un output.

Per saperne di più, leggi il capitolo dedicato alle architetture de “Il Libro Open Source”.