In questa seconda parte dedicata alle architetture event-driven, parliamo degli eventi: cosa sono e, soprattutto, cosa non sono?

Cos’è un evento

Come già detto nell’introduzione a questa serie di articoli, la Event-Driven Architecture è un pattern di comunicazione, più che una architettura vera e propria; è necessario quindi definire, prima di tutto, come un sistema possa far comunicare i suoi componenti in questo contesto.

Esempio di architettura event-driven

Come dice il nome stesso, l’architettura è basata sugli eventi, ma è importante definire cosa sia un evento e, di conseguenza, cosa non lo sia.

Un evento è la documentazione immutabile di un cambiamento di stato avvenuto nel sistema.

Sì, ma cosa vuol dire? Prendiamo questa frase e scomponiamola in parti più piccole.

Documentazione immutabile

Un evento è un’informazione che viene registrata in modo immutabile, ovvero che non può essere modificata. Questo è fondamentale perché, se un evento può essere modificato, non possiamo sapere chi lo abbia fatto e perché, e di conseguenza non risulterebbe più affidabile.

Ad esempio, se un evento informa il sistema dell’avvenuto pagamento di una transazione X di importo €10 e, successivamente, questo evento viene mutato in un evento di importo €100, il sistema non avrà modo di sapere se il pagamento è stato effettuato per €10 o per €100 e perché, e in caso di storno o rendicontazione, non saprebbe riconciliare i dati in suo possesso. In questi casi, infatti, è necessario registrare un nuovo evento - Variazione di €90 in positivo dell’importo della transazione X -, che sia a sua volta immutabile.

Cambiamento di stato

Per cambiamento di stato si intende una situazione in cui un oggetto, un’entità o un sistema passa da uno stato a un altro. Questo cambiamento può essere causato da un’azione interna o esterna al sistema stesso.

Un esempio di cambiamento di stato è il pagamento di una fattura: il sistema che gestisce le fatture, ricevuto il pagamento, cambia lo stato della fattura da Non pagata a Pagata, emettendo un evento che documenta questo cambiamento - Pagamento della fattura X. -.

Questo evento sarà poi consumato da altri sistemi che, in base al suo contenuto, potranno eseguire delle azioni.

Avvenuto nel sistema

Una nota importante è che un evento non rappresenta la modifica di un dato (Es. Aggiornamento dello stato della transazione X da “Da Pagare” a “Pagata”), ma il cambiamento di stato da un punto di vista di business (Es. Pagamento della fattura X).

Questo è importante perché, se un evento rappresentasse la modifica di un dato, esso sarebbe legato al sistema che lo ha generato, creando quello che nel mondo dell’architettura software viene chiamato alto accoppiamento (high coupling), rendendo più arduo il mantenimento e l’evoluzione del sistema stesso.

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