I sistemi legacy sono ancora oggi il cuore pulsante di molte infrastrutture aziendali. Stabili, consolidati, affidabili… ma profondamente rigidi. In un mondo dove il business evolve alla velocità del digitale, l’accoppiamento tra componenti legacy e nuove soluzioni può diventare un freno all’innovazione.
Il disaccoppiamento architetturale è la chiave per liberare il potenziale di evoluzione delle applicazioni, senza dover riscrivere tutto da zero. Una delle strategie più efficaci per farlo è adottare una event-driven architecture (EDA).
Cos’è una architettura event-driven?
L’architettura event-driven è un modello in cui i componenti software comunicano tra loro tramite eventi, ovvero notifiche che descrivono un cambiamento di stato.
Invece di chiamare direttamente altri servizi (approccio sincrono), ogni sistema pubblica eventi su un event broker (come Kafka, RabbitMQ, EventBridge…), a cui altri servizi possono “abbonarsi” e reagire in modo asincrono.
I vantaggi chiave:
- Disaccoppiamento forte: i produttori di eventi non devono conoscere i consumatori
- Scalabilità naturale: ogni servizio può scalare in base al volume di eventi
- Resilienza: le componenti possono fallire indipendentemente senza bloccare l’intero sistema
- Estendibilità: nuovi consumatori possono essere aggiunti senza modificare i produttori.
Il problema dei sistemi legacy
I sistemi legacy sono spesso:
- Monolitici
- Basati su comunicazione sincrona (RPC, SOAP, SQL tightly coupled)
- Difficili da testare e monitorare
- Stretti colli di bottiglia per l’integrazione con servizi moderni (API, microservizi, front-end evoluti).
Il risultato? Qualsiasi nuovo progetto si trova costretto a dipendere da logiche interne non pensate per essere riutilizzate o estese.
L’approccio event-driven per il disaccoppiamento
Step 1: Identificare i “trigger” chiave del legacy
Non serve disaccoppiare tutto: è strategico iniziare da eventi di business rilevanti, come:
- Creazione/modifica di un ordine
- Aggiornamento stock
- Esito di pagamento
- Emissione documento
Step 2: Creare un event stream
Introdurre un event broker centrale che riceve notifiche dal sistema legacy (es. via trigger DB, polling, CDC).
Esempio: da un ERP legacy esce un evento OrderCreated, che viene pubblicato su Kafka.
Step 3: Introdurre consumatori progressivi
I nuovi servizi (es. microservizi, front-end, sistemi di AI o analytics) si collegano come consumer e reagiscono all’evento pubblicato, in modo autonomo e disaccoppiato.
Risultato: il legacy continua a vivere, ma il resto dell’ecosistema IT può evolversi liberamente.
Quando NON è la soluzione giusta?
L’approccio event-driven richiede governance e maturità. Non è ideale quando:
- I team non sono pronti a gestire concetti di eventual consistency
- Non esiste una strategia chiara di schema evolution per gli eventi
- Il sistema legacy è troppo chiuso per generare eventi in tempo utile
In questi casi è meglio procedere con step intermedi (ESB, API façade, batch)
Conclusione: un ponte tra legacy e modernità
L’event-driven architecture non è solo una moda. È una leva concreta per disaccoppiare sistemi legacy e costruire soluzioni moderne, resilienti e scalabili in modo progressivo. Non serve riscrivere tutto. Serve solo iniziare a spostare la logica di integrazione dal centro al bordo, e lasciar parlare gli eventi.