Cos'è l'anti-corruption layer nel codice?

L'anti-corruption layer (ACL) è un pattern architetturale introdotto da Eric Evans nel libro Domain-Driven Design: Tackling Complexity in the Heart of Software (2003): uno strato di traduzione che si interpone tra il modello di dominio interno di un'azienda e un sistema esterno, un fornitore SaaS, un vendor cloud o un'applicazione legacy, in modo che i modelli, le API e le assunzioni di quel sistema esterno non "contaminino" il codice di business. In pratica, il codice interno non chiama mai direttamente le API del fornitore: parla con un'interfaccia propria, stabile, disegnata secondo il linguaggio del proprio dominio, e solo l'ACL traduce quelle chiamate nel formato specifico di quel fornitore. Senza questo strato, i tipi di dato e i vincoli del fornitore finiscono sparsi in decine di punti del codice, e cambiare fornitore significa riscrivere ogni punto che lo tocca, non un singolo modulo isolato. L'ACL non elimina la dipendenza contrattuale, la isola a livello di codice.

Perché conta oggi: i fornitori cambiano condizioni, non solo tecnologia

Il pattern nasce nel 2003 come disciplina di modellazione, ma la sua urgenza pratica è cresciuta con la dipendenza da servizi esterni che possono cambiare prezzo o uscire dal mercato senza preavviso proporzionato. Dopo l'acquisizione di VMware da parte di Broadcom nel 2023, una ricerca CloudBolt citata da TechRadar ha rilevato che il 59% dei clienti ha visto rinnovi con aumenti superiori al 25%, con casi estremi tra il 350% e il 700%. Nel 2018 Google ha ristrutturato il pricing delle Maps API con poche settimane di preavviso tra l'annuncio e l'entrata in vigore, e gli sviluppatori che chiamavano l'API direttamente in decine di punti del codice si sono trovati a dover intervenire ovunque in tempi stretti, non in un solo modulo di integrazione. In entrambi i casi il danno tecnico non è stato l'aumento in sé, ma il fatto che l'API o la licenza del fornitore fosse cablata nel codice di dominio: chi aveva isolato quella dipendenza dietro un confine ha potuto valutare alternative con calma, chi non l'aveva fatto ha dovuto agire sotto pressione.

Un esempio enterprise

Un'azienda integra un fornitore di pagamenti chiamando il suo SDK direttamente dai controller dell'e-commerce, dal modulo abbonamenti e dal cruscotto amministrativo: i codici di errore, i formati di importo e i webhook del fornitore diventano parte del linguaggio interno con cui il team ragiona di "pagamento riuscito" o "carta rifiutata". Quando il fornitore cambia struttura di prezzo o modifica l'API in una nuova versione, ogni punto che lo chiama va rivisto, testato e rilasciato, e la finestra di migrazione forzata coincide quasi sempre con il periodo di minore libertà negoziale. Con un ACL, i controller e il modulo abbonamenti parlano con un'interfaccia interna ("elabora pagamento", "importo in centesimi", "esito autorizzato/rifiutato") e un solo modulo traduce quella interfaccia nelle chiamate specifiche del fornitore. Cambiare fornitore, o aggiungerne un secondo per ridurre la dipendenza da fornitore unico, resta un lavoro concentrato in quel modulo, non una revisione trasversale di tutto il codice business.

Perché conta per chi decide

L'ACL non è un accorgimento di stile del codice, è una decisione che sposta dove finisce il costo di un cambio di fornitore: dentro un confine progettato, o sparso ovunque nel codice di produzione. Chi valuta un nuovo fornitore critico (pagamenti, cloud, un modello AI di terze parti) dovrebbe chiedere esplicitamente se l'integrazione prevede questo strato o se il fornitore verrà chiamato direttamente dal codice di dominio, perché è quella scelta, non il vendor lock-in contrattuale in sé, a determinare quanto costerà uscire quando il fornitore alzerà i prezzi o cambierà condizioni. È una scelta architetturale da prendere all'inizio dell'integrazione, quando il costo di isolare è basso, non quando il rinnovo arriva con un aumento a tre cifre.