Architettura esagonale: perché ogni dev dovrebbe farsela amica

Vantaggi e sfide dell'architettura esagonale

Parliamo di architettura. Non quella con i mattoni, ma di un pattern software che fa brillare gli occhi a chiunque abbia mai dovuto mantenere un’app seria senza voler cambiare mestiere dopo tre deploy: l’architettura esagonale.

Se sei un dev frontend e pensi “meh, roba da backend”, fermati: l’architettura esagonale ti riguarda più di quanto pensi. Perché? Perché si tratta di un modo di progettare il software che ti permette di non dover riscrivere tutto da capo ogni volta che cambia qualcosa intorno a te (tipo: API, DB, framework, business logic, capricci del product owner).

Cos’è l’architettura esagonale?

Non c’entra nulla con gli alveari.

L’architettura esagonale, detta anche Ports and Adapters, è un pattern ideato da Alistair Cockburn con un obiettivo preciso: separare il core della tua applicazione (quello che fa le cose) dal mondo esterno (quello che rompe le scatole). Lo fa disegnando l’app come un esagono – ma poteva essere un cerchio – in cui il cuore della logica è isolato e comunica con l’esterno solo tramite “porte” (interfaces) e “adattatori” (implementazioni concrete).

In parole povere: il tuo business non dovrebbe fregarsene se usi Postgres o Mongo, se le chiamate arrivano via REST o GraphQL, se il frontend è in React o Svelte.

Ma quindi è una roba nuova?

Assolutamente no.

Il paper originale è del 2005, ma le sue radici affondano nella tradizione del Domain-Driven Design (DDD) e nell’idea che la logica di business vada protetta come un panda in via d’estinzione.

La verità? In altri contesti (USA, UK, Germania) è uno standard da anni. Ma in Italia, come spesso accade, abbiamo la tendenza a scoprire le cose quando diventano trend su LinkedIn. Ed ecco che ora tutti parlano di “esagonale”, “clean”, “onion”, manco fosse l’ultima hype library di JavaScript.

Meglio tardi che mai. Però attenzione: adottare l’architettura esagonale non significa solo fare più file con nomi altisonanti. È un cambio di mentalità.

I tre principi guida

1. Indipendenza dall’infrastruttura
   La logica applicativa vive beata senza sapere nulla del database, delle API esterne o del framework web. Zero coupling, massima serenità.
2. Dipendenze direzionali
   Le dipendenze vanno sempre verso il core. Mai il contrario. Questo vuol dire che al dominio non importa delle tecnologie che usi fuori – e questa è una cosa bellissima.
3. Testabilità estrema
   Separare bene le responsabilità significa che puoi testare il tuo dominio senza dover alzare un server, connetterti a un DB o mockare l’ennesima fetch.

Vantaggi (anche se fai solo il CSS™)

Mantenibilità

Quando il dominio è isolato, ogni modifica non diventa un terremoto. Cambi il database? Scrivi un nuovo adapter. Cambi il canale di comunicazione? Aggiungi una nuova porta.

Riutilizzabilità

Una buona architettura esagonale ti permette di riutilizzare la logica di dominio su più fronti: web app, mobile, CLI, API. Un solo cervello, mille corpi.

Test più facili

I test sul dominio non hanno side effect. Niente HTTP, niente DB, solo logica pura. È come allenarsi in palestra senza il rischio di slogarsi la spalla.

Scalabilità dei team

Frontend, backend, DevOps: ognuno può lavorare su un layer diverso senza pestarsi i piedi. E il dominio resta il contratto comune tra tutti.

Ma funziona anche nel frontend?

Sì, soprattutto se lavori in un contesto serio. Separare business logic, presentazione e infrastruttura è il modo più sano per scalare una SPA (o anche solo capire cosa stai facendo tra due sprint). Con un po’ di accortezza, puoi usare pattern ispirati all’esagonale anche nel frontend: pensa a come strutturi hooks, servizi, modelli e componenti.

Quando NON è la scelta giusta

Facciamo un bagno di umiltà. L’architettura esagonale è potente, ma non è una panacea.

Ecco alcuni casi in cui potresti evitarla:

• Progetti piccoli, a breve vita: Se devi buttare su un MVP in tre giorni o una landing page con due API e un form, introdurre un layer di astrazione in più è solo rumore.
• Team inesperti o inesperti con il pattern: Una cattiva implementazione dell’esagonale può creare più confusione che ordine. Se non sai distinguere un adapter da un gateway, forse è meglio iniziare con qualcosa di più lineare.
• Prestazioni critiche e overhead minimo: Ogni strato ha un costo. In contesti con requisiti di latenza al millisecondo (game engine, microservizi realtime), potresti preferire qualcosa di più snello.

Insomma, non è che se non usi l’architettura esagonale sei un barbaro. Basta sapere cosa stai facendo. E perché.

Un esempio veloce

Supponiamo di avere un’app che calcola preventivi. Il core è un modulo che riceve dei parametri e restituisce un risultato. A quel modulo non importa se i dati arrivano da un form, da un’API o da un CSV. Quelli sono adapter. Il modulo centrale si testa da solo, come un dio greco isolato dall’umana stupidità.

Conclusione

L’architettura esagonale non è la moda del momento, ma un pattern maturo e affidabile che ti aiuta a scrivere software che non ti tradisce al primo refactor.

È un approccio, non una religione. Ti insegna a mettere la logica al centro e tutto il resto ai margini. E se ti capita di lavorare su progetti con ambizioni serie, ti renderai conto che è una delle migliori decisioni architetturali che puoi prendere.

Nel dubbio, se il tuo dominio sa cos’è un HTTP request, stai sbagliando strada.

Se sei pronto a vedere le cose da una nuova prospettiva, iscriviti a SenseiTales, la nostra inimitabile newsletter. Dentro ci trovi quello che viviamo davvero: progetti concreti, idee che funzionano, risorse che servono. Zero frasi fatte, zero vendite forzate. Solo contenuti pensati per darti valore.