Cos'è l'architettura esagonale e perché implementarla?
La scelta dell'architettura della tua applicazione web o mobile avviene in genere all'inizio del progetto, durante la fase di progettazione tecnica. Questo elemento condiziona il modo in cui risolverai i problemi ricorrenti di progettazione della tua applicazione, di rappresentazione del business, di testabilità unitaria e di integrazione. Questa architettura è anche determinante per la sostenibilità dell'applicazione che sviluppi. È, per un'agenzia di creazione di applicazioni di business o un'agenzia di creazione di applicazioni mobili, il ruolo del Responsabile dello Sviluppo quello di definire questa architettura.
Esistono diversi modelli di pattern di architettura, o design patterns. I pattern strategici, che permettono di sapere come costruire la tua applicazione (il loro utilizzo è consigliato per l'identificazione dei contesti di business), e i pattern tattici, che permettono di costruire il prodotto correttamente. L'architettura esagonale, oggetto di questo articolo, fa parte di questa seconda categoria, allo stesso titolo del Domain Driven Design (DDD).
L'architettura esagonale, un modello di progettazione applicativa orientato al business
L'origine dell'architettura esagonale
È Alistair Cockburn, cofirmatario nel 2001 del Manifesto agile, all'origine dell'architettura esagonale. L'obiettivo di questo pattern di architettura creato nel 2005 è evitare i problemi incontrati sulle architetture di tipo MVC (Model-View-Controller) con le quali esiste un miscuglio di strati (dipendenza della vista e del modello, del controller e della vista, del modello e del controller) rendendo difficili la realizzazione di test unitari e la manutenzione del codice. Questo impatta anche le performance dell'applicazione.
Questo tipo di modello complica le modifiche sulle logiche di business, con potenzialmente regressioni ed effetti collaterali pregiudizievoli all'integrità dell'applicazione.
L'architettura esagonale corrisponde al concetto di clean architecture. Questa mira a ridurre le dipendenze della logica di business dalle infrastrutture tecniche per mantenere la stabilità dell'applicazione lungo tutto il suo ciclo di vita (fase di aggiornamento e test), ma anche durante le evoluzioni tecniche dell'infrastruttura.
I principi di base dell'architettura esagonale
Il principio dell'architettura esagonale si basa su:
La separazione esplicita dei tre strati che compongono l'architettura. Al centro dell'esagono, la business logic (logica di business) è il cuore del reattore. All'esterno dell'esagono si trova l'infrastruttura. È composta dall'user-side, che raggruppa tutti gli elementi che interrogheranno il dominio (console utente, controller, strati REST, Event Streaming, Batch Launcher, ecc.), e dal server-side, corrispondente a tutti gli elementi (informazioni/servizi) di cui l'applicazione ha bisogno per funzionare (database, file system, web services…).
Le dipendenze, che vanno esclusivamente dall'esterno, blocchi user-side e server-side, verso il dominio.
Le interazioni tra le parti infrastruttura e business, che sono gestite da porte e adapters API (Application Programming Interface) e SPI (Service Provider Interface).
Le API e le SPI sono all'interno dell'esagono e manipolano solo gli oggetti di business del dominio. Le API forniscono le interfacce per interrogare il dominio, e le SPI concentrano le interfacce necessarie al dominio per recuperare i dati da moduli di terze parti. Queste interfacce sono sfruttate all'interno dell'esagono e sono implementate dagli elementi dell'infrastruttura del server-side.
L'architettura esagonale è anche chiamata Ports & Adapters Architecture. Le porte di comunicazione del dominio sono le API e le SPI, e gli adattatori sono i moduli di infrastruttura che le implementano e li utilizzano.
Il principio di questa architettura è quindi quello di isolare la logica di business, che è all'interno dell'esagono, dai processi tecnici che sono all'esterno, l'esagono rappresentando una frontiera tra il codice tecnico e il codice di business. Non esiste alcuna dipendenza tra questi due mondi. Il dominio di business è strettamente indipendente dagli elementi tecnici come la gestione dei protocolli di comunicazione, i flussi, la presentazione (logica dell'interfaccia utente), ecc. Per questo, un lavoro di design è fatto a monte per identificare tutto ciò che costituisce la logica di business e posizionare questi elementi all'interno dell'esagono.
I benefici dell'utilizzo di un'architettura esagonale
Indipendenza degli strati di business e infrastruttura tecnica
Il vantaggio principale dell'architettura esagonale è quello di garantire l'indipendenza del blocco di business, situato all'interno dell'esagono, dalla parte infrastruttura posizionata all'esterno. Isolando il codice di business dal resto dell'applicazione, questa architettura garantisce la riutilizzabilità della rappresentazione del business.
Testabilità al 100% del dominio di business
Un altro vantaggio dell'architettura esagonale è la sua testabilità. Essendo tutte le problematiche tecniche di infrastruttura e di integrazione trattate indipendentemente, i test funzionali interagiscono direttamente con il dominio di business, senza interferenze con gli altri strati.
La testabilità del dominio di business è così aumentata, con una copertura al 100% tramite test unitari. I test di integrazione che riguardano gli aspetti di infrastruttura sono un po' più lenti, ma essendo isolati, preservano l'integrità del dominio di business.
Modularità e scalabilità
L'architettura esagonale essendo disaccoppiata, può integrare una grande diversità di adapters. Questa potente modularità permette di far coabitare simultaneamente strati diversi senza impattare il dominio di business.
Evolutività tecnica e funzionale
Grazie a questa architettura disaccoppiata, le evoluzioni tecniche e funzionali sono facilitate. Ad esempio, lato SPI, durante la migrazione di un database SQL verso un database NoSQL, il resto dell'applicazione non è impattato e la sostenibilità del codice di business non è messa in discussione. Allo stesso modo, quest'ultimo può essere implementato in un'altra architettura esagonale e funzionare con un'infrastruttura diversa.
Un approccio di business in linea con le aspettative dei clienti
Lo strato di business è l'elemento centrale del dispositivo. All'inizio, i team di progetto possono focalizzarsi sul design della logica di business e sulle funzionalità attese. Hanno così una perfetta comprensione delle esigenze del cliente e possono rimandare in un secondo momento le scelte tecniche affinché corrispondano al meglio alle esigenze del progetto.
Metodo di progettazione
Per ottimizzare l'utilizzo di un'architettura esagonale, bisogna iniziare il progetto dall'interno dell'esagono, lo strato di business. È il valore aggiunto dell'applicazione per il cliente e l'elemento che deve guidare le scelte, più che la tecnica pura. L'avvio del progetto è allora più rapido poiché gli aspetti di infrastruttura arrivano in un secondo tempo, ed è allora possibile consegnare più rapidamente le funzionalità di business.
In seguito bisogna anche concentrarsi sulle funzionalità piuttosto che sui dettagli tecnici e decidere l'implementazione tecnica giusto prima di entrare nella fase di sviluppo. In generale, è difficile determinare all'inizio di un progetto l'implementazione tecnica più adatta per rispondere alle esigenze. Il disaccoppiamento della logica di business dall'infrastruttura tecnica è la garanzia della qualità del dominio di business, della sua durabilità e della sua robustezza di fronte alle continue evoluzioni tecniche.
