{"id":8376,"date":"2026-02-11T15:34:07","date_gmt":"2026-02-11T14:34:07","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8376"},"modified":"2026-02-11T16:32:06","modified_gmt":"2026-02-11T15:32:06","slug":"architetture-event-driven-a-km0-dal-producer-al-consumer-parte-2","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/architetture-event-driven-a-km0-dal-producer-al-consumer-parte-2\/","title":{"rendered":"Architetture Event-Driven a KM0: dal producer al consumer – Parte 2"},"content":{"rendered":"\n

Nell\u2019articolo precedente: “Architetture Event-Driven a KM0: dal producer al consumer<\/a>” abbiamo esplorato le basi concettuali delle architetture Event-Driven, analizzando gli attori coinvolti, le tipologie di messaggi, i canali di messaging e i pattern di coupling che regolano l\u2019interazione tra producer e consumer.<\/p>\n\n\n\n

In questo secondo articolo ci concentreremo su come realizzare un\u2019Event-Driven Architecture su AWS, con Amazon EventBridge come servizio centrale. EventBridge va oltre il semplice trasferimento dei dati: funge da event router, orchestrando il flusso tra producer e consumer e gestendo filtraggio, trasformazione e instradamento degli eventi. Il servizio fornisce inoltre l\u2019infrastruttura necessaria per instradare eventi sia tecnici sia di dominio, provenienti da servizi AWS nativi, applicazioni SaaS o soluzioni custom.<\/p>\n\n\n\n

L’event bus<\/h2>\n\n\n\n

In base al tipo di eventi che gestiamo, dobbiamo scegliere la tipologia di event bus pi\u00f9 adatta. Ogni account AWS dispone di un default event bus per regione, dove vengono automaticamente instradati gli eventi emessi dai servizi AWS integrati con EventBridge. Quando si tratta di eventi di dominio, potremmo tecnicamente usare il default event bus come destinazione, ma suggerisco di utilizzare un nuovo custom event bus dedicato alla nostra applicazione, per garantire isolamento, governance pi\u00f9 chiara e separazione tra eventi infrastrutturali e logica di business.<\/p>\n\n\n\n

L’event envelope<\/h2>\n\n\n\n

Ora che abbiamo un’idea pi\u00f9 chiara di dove, concentriamoci su cosa fluisce nell’event bus.<\/p>\n\n\n\n

Per inviare un evento a un custom event bus, dobbiamo invocare l’API PutEvents. Quello che segue \u00e8 un esempio di come possiamo invocarla usando AWS CLI.<\/p>\n\n\n\n

aws events put-events --entries '[{\n    \"Source\": \"it.besharp.service\",\n    \"DetailType\": \"customEvent\",\n    \"Detail\": \"{\n        \\\\\\\\\"metadata\\\\\\\\\": {\n            \\\\\\\\\"event-name\\\\\\\\\": \\\\\\\\\"custom-event-name\\\\\\\\\",\n            \u2026\n        },\n        \\\\\\\\\"data\\\\\\\\\": {\n            \\\\\\\\\"key\\\\\\\\\": \\\\\\\\\"value\\\\\\\\\",\n            \u2026\n        }\n    }\",\n    \"EventBusName\": \"custom-event-bus\"\n}]'\n<\/code><\/pre>\n\n\n\n
DetailType si riferisce al “tipo di evento”; suggerisce i campi che faranno parte dell’envelope.<\/p>\n\n\n\n
L’event envelope \u00e8 rappresentato dal campo Detail. Il valore associato a tale campo deve corrispondere ad un JSON valido. \u00c8 pratica comune utilizzare una struttura standard, come “Metadata \/ Data”. I campi Metadata sono pensati per essere applicati a tutti gli eventi, mentre Data contiene campi specifici per tipo di evento (DetailType).<\/p>\n\n\n\n
“Metadata \/ Data” non \u00e8 l’unico approccio standard esistente: quest<\/a>a<\/a> \u00e8 una valida alternativa. \u00c8 comunque possibile definire la propria struttura, purch\u00e9 fornisca informazioni consistenti e significative ai consumer.<\/p>\n\n\n\n
La resource policy<\/h2>\n\n\n\n
Una volta preparato l’evento, possiamo inviarlo al custom event bus. La prima barriera che l’evento incontra \u00e8 la Resource Policy \u2014 ma diventa obbligatoria solo se stai inviando eventi a un bus in un account AWS diverso.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\nSe producer ed event bus sono all’interno dello stesso account, i permessi IAM sono sufficienti per l’autorizzazione: l\u2019access policy legata al producer necessita solo del permesso events:PutEvents<\/strong><\/code> per inviare l\u2019evento all\u2019event bus. \n\n\n\n
\u00c8 possibile aggiungere una resource policy per un controllo aggiuntivo (come limitare quali principal possono pubblicare in base a condizioni specifiche), ma non \u00e8 obbligatorio, finch\u00e9 producer ed event bus sono all\u2019interno dello stesso account. Lo stesso vale per il default bus che riceve eventi dai servizi AWS; nessuna resource policy \u00e8 necessaria.<\/p>\n\n\n\n
Immaginiamo di avere una Custom App nell’Account A che deve inviare eventi a un Custom Event Bus nell’Account B.<\/p>\n\n\n\n
Configuriamo il nostro producer – una Lambda Function – con un\u2019access policy che punta al bus dell’Account B; effettuiamo il deploy; proviamo a pubblicare un evento ma… EventBridge blocca la richiesta perch\u00e9 l’accesso cross-account richiede che entrambe le parti siano d’accordo.<\/p>\n\n\n\n
In particolare:<\/p>\n\n\n\n