Quante volte abbiamo sentito dire: “Ma no, figurati, non cambieremo mai il database della nostra applicazione!”
E poi… succede. Così come può capitare di dover sostituire un provider esterno, un servizio di terze parti o un’intera API di integrazione.

Come possiamo evitare che un cambiamento del genere diventi un incubo? La risposta sta tutta nelle astrazioni ben progettate.

In questa sessione vi racconterò alcune storie dal mio passato. Storie in cui, grazie all’Hexagonal Architecture, sono riuscito non solo a ridurre drasticamente l’impatto di cambiamenti radicali, ma anche a rendere un applicativo utilizzabile in contesti e per clienti diversi, senza doverlo riscrivere ogni volta.

Durante la conferenza vedremo:
- perché incorporare dipendenze esterne direttamente nel nostro codice può diventare un problema serio nel medio-lungo periodo;
- che cos’è davvero l’Hexagonal Architecture e come si distingue da Clean Architecture e Onion Architecture;
- alcuni casi reali in cui l'Hexagonal Architecture si è rivelata determinante per salvare un progetto, permettermi di sperimentare, e ridurre i tempi di sviluppo.

Gli esempi saranno in .NET, ma i principi e i pattern discussi sono applicabili a qualsiasi linguaggio di programmazione.