{"id":7949,"date":"2025-07-30T15:39:17","date_gmt":"2025-07-30T13:39:17","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7949"},"modified":"2025-07-30T17:08:55","modified_gmt":"2025-07-30T15:08:55","slug":"architetture-event-driven-a-km0-dal-producer-al-consumer","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/architetture-event-driven-a-km0-dal-producer-al-consumer\/","title":{"rendered":"Architetture Event-Driven a KM0: dal producer al consumer"},"content":{"rendered":"\n
Introduzione<\/h2>\n\n\n\n
In questo primo di due articoli, approfondiamo un argomento noto da tempo ma recentemente al centro di un interesse crescente: le Architetture Event-Driven ed Event-Based (EDA).<\/p>\n\n\n\n
Nonostante se ne parli sempre pi\u00f9 spesso, questo non significa che l\u2019argomento sia diventato pi\u00f9 chiaro. L\u2019obiettivo di questi articoli \u00e8 offrire una spiegazione semplice e comprensibile dei principi fondamentali alla base di questi paradigmi architetturali.<\/p>\n\n\n\n
Al centro delle EDA si trovano due ruoli principali: il Producer e il Consumer. Il Producer ha il compito di generare e inviare un messaggio. Dall’altro lato, il Consumer riceve questo messaggio e reagisce, tipicamente eseguendo una logica di business o attivando un flusso di lavoro. Questa interazione costituisce la spina dorsale del flusso informativo nelle EDA.<\/p>\n\n\n\n
La semantica degli eventi<\/h2>\n\n\n\n
Un messaggio pu\u00f2 rappresentare diversi tipi di comunicazione a seconda dell’intento del Producer. Pi\u00f9 comunemente, i messaggi si dividono in due categorie: comandi ed eventi.<\/p>\n\n\n\n
Un comando viene utilizzato quando il Producer desidera richiedere un’azione specifica al Consumer. I comandi sono tipicamente imperativi e si aspettano un certo risultato o effetto collaterale.<\/p>\n\n\n\n
Al contrario, un evento serve per notificare qualcosa che \u00e8 accaduto \u2014 spesso rappresentando un cambiamento di stato o il verificarsi di un evento di business rilevante. A differenza dei comandi, gli eventi non si aspettano una risposta diretta o un’azione da parte del Consumer.<\/p>\n\n\n\n
Questa distinzione tra comandi ed eventi \u00e8 fondamentale per comprendere come comunicano i componenti nelle EDA e influenza profondamente il modo in cui vengono progettati i sistemi.<\/p>\n\n\n\n
Canali di messaggistica<\/h2>\n\n\n\n
Un Producer sfrutta canali di messaggistica per inoltrare i messaggi verso i Consumer. Come osserva Gregor Hohpe in uno dei suoi \u201cramblings\u201d, le EDAs sono comunemente associate ai canali Publish-Subscribe (Pub\/Sub), poich\u00e9 pi\u00f9 destinatari possono essere interessati a reagire ad un singolo evento. Questo si contrappone ai canali Point-to-Point, che sono tipicamente usati per inviare comandi o documenti a un singolo Consumer.<\/p>\n\n\n\n
Nell’ecosistema AWS, questi due tipi di canali sono ben rappresentati: le code SQS rappresentano i canali Point-to-Point, mentre i topic SNS sono una chiara implementazione di canali Publish-Subscribe. Con le code SQS, ogni messaggio \u00e8 indirizzato a un solo Consumer \u2014 solitamente un worker o un’applicazione che estrae messaggi dalla coda \u2014 garantendo che venga processato una sola volta. Al contrario, i topic SNS permettono che un singolo messaggio venga inviato a pi\u00f9 consumatori, detti subscriber, che si sono sottoscritti al topic. Questo modello consente una comunicazione decentrata, in cui gli eventi possono propagarsi simultaneamente a diversi sistemi, supportando scalabilit\u00e0 ed estensibilit\u00e0.<\/p>\n\n\n\n
<\/p>\n\n\n
\nCanale di messaggistica Point-to-Point<\/em><\/figcaption><\/figure><\/div>\n\n\n
<\/p>\n\n\n
\nCanale di messaggistica Publish-Subscribe<\/em><\/figcaption><\/figure><\/div>\n\n\n