Un anno di architettura esagonale in Laravel: cosa ha funzionato, cosa no e cosa ho cestinato

Abstract

Laravel permette di sviluppare rapidamente, ma la stessa flessibilità che lo rende così produttivo può trasformarsi in un problema quando una codebase cresce.

Un anno fa ho deciso di adottare una versione pragmatica dell’architettura esagonale: tre layer (Domain, Application e Infrastructure), una sola regola di dipendenza e nessuna astrazione introdotta “per principio”. Da allora l’ho applicata a tutti i nuovi progetti e utilizzata per migrare due applicazioni esistenti.

In questo talk racconterò cosa ha funzionato davvero: il test del ‘togli il framework’, l’uso delle Actions come unità applicative e la validazione automatica dell’architettura in CI. Ma parlerò anche di ciò che ho eliminato lungo il percorso: repository che replicano 1:1 Eloquent, service layer ridondanti, transazioni e FormRequest mescolati alla logica applicativa.

Un resoconto concreto, fatto di compromessi, errori e decisioni pratiche, da cui sono nate convenzioni riutilizzabili e un package open source che oggi utilizzo come base per strutturare applicazioni Laravel mantenibili nel tempo.