Parlando di architettura esagonale

Uno dei problemi frequenti dello sviluppo software degli ultimi anni, è legato alla penetrazione di logiche di business nel codice di user interface.

26 giu 2015

Uno dei problemi frequenti dello sviluppo software degli ultimi anni, è legato alla penetrazione di logiche di business nel codice di user interface.

 

La problematica che ne deriva può avere diverse chiavi di lettura: il sistema non può essere affiancato da test suite automatizzate poiché parte delle logiche che devono essere testate sono dipendenti da logiche residenti in UI la quale è caratterizzata da una variabilità maggiore rispetto a quella del business; a causa di ciò, diventa impossibile sostituire le interazioni umane sul sistema con operazioni batch e diventa difficile quando non impossibile lasciare che sia un altro sistema a pilotare quello in esame. L’esigenza è fortemente sentita rispetto ad un decennio fa, poiché le applicazioni si trovano a dover interagire con sistemi allora non contemplati come sistemi esterni (tra i quali si distinguono smartphone e tablet) che comunicano in formati diversi o sistemi automatici come possono essere quelli di monitoraggio o gestione eventi.

 

La soluzione proposta, è tipicamente quella di definire un nuovo layer nell’architettura, con la promessa che nessuna logica di business venga in esso implementata ma poiché tale confine è teorico e non esistono meccanismi in grado di garantire il rispetto di tale regola, con il tempo la promessa è destinata ad essere disattesa ed il vecchio problema riappare.

 

Immaginando che ogni funzionalità esposta dall’applicazione sia fruibile attraverso un’API, potrebbe essere predisposta una suite di test di regressione. Gli esperti di dominio potrebbero definire test case automatizzati prima ancora che i dettagli di UI siano finalizzati. La disponibilità delle API favorirebbe la distribuzione dell’applicazione, in modo che altri programmi potrebbero consumare le funzionalità senza richiedere l’intervento umano e considerazioni simili possono essere fatte relativamente alla persistenza del dati del sistema: l’eventuale indisponibilità del database non dovrebbe compromettere la fase di sviluppo.

 

Si evince, quindi, come un approccio “layered” sia troppo debole di fronte alle suddette riflessioni ed in tal senso viene rafforzata la teoria delle architetture esagonali (anche dette ports and adapters) introdotte da Alistar Cockburn,  secondo il quale l’applicazione in sviluppo deve essere isolata dai sistemi esterni con i quali comunica mediante porte che definiscono un protocollo di comunicazione (API) ed adapter che consentono ai diversi mondi di comunicare. In una classica architettura a layer, la chiave di lettura è dall’alto verso il basso (o da sinistra a destra nel caso di architetture n-tier); in questo caso la lettura è dal centro verso l’esterno. Nel contesto di un’architettura n-tier, vige un’asimmetria tra utenti e sistemi contattati: i primi agiscono da attori principali, ossia coloro che guidano l’applicazione mentre i sistemi contattati sono gli attori secondari. Prende forma l’applicazione come nucleo isolato da tutto quanto le “orbita” attorno. L’architettura può essere paragonata a quella di un sistema operativo dove ogni device (sistema esterno) che aderisce al protocollo di una porta può essere collegato sfruttando i moduli (adapter) del kernel.

 

Una GUI, è un esempio di adapter che mappa le azioni dell’utente sulle API della porta. L’applicazione comunica con entità esterne per recuperare i dati su cui operare: siamo in presenza di un protocollo di tipo database, ma dal punto di vista dell’applicazione se il database SQL venisse sostituito da un file o un database NOSQL l’API non dovrebbe cambiare ma un differente adapter dovrebbe essere sostituito per operare sulla medesima porta. Per molte applicazioni sono sufficienti due porte: la UI ed il database. Questa semplificazione, può comportare alla creazione di applicazioni con rappresentazione mono dimensionale a tre, quattro o cinque layer. Si riscontrano almeno due problematiche legate a questa scelta: la prima (e forse la peggiore) implica che le persone tendono a non tracciare una linea netta tra i layer incappando in quanto detto in apertura, ovvero che le logiche dell’applicazione non rimangono confinate; secondariamente potrebbero esistere più di due porte per l’applicazione cosicché la rappresentazione mono dimensionale diviene insufficiente. La rappresentazione esagonale si propone per evidenziare l’asimmetria tra ciò che sta dentro e ciò che sta fuori e la presenza di un numero definito di differenti porte. Queste non devono essere necessariamente sei, l’esagono è simbolicamente eletto poiché consente una facile rappresentazione del numero di porte e adapter di cui le persone hanno bisogno. Il termine architetture esagonali nasce quindi dall’effetto visivo. Il termine port ed adapter coglie lo scopo della rappresentazione: per ciascuna porta possono essere definiti più adapter per le diverse tecnologie che possono adattarsi a tale porta.