Descrizione

La Clean Architecture ha una struttura a cipolla: come si pu`o evincere dalla figura, i cerchi concentrici rappresentano le differenti aree di competenza e pi`u ci si allontana dal centro, pi`u aumenta l’astrazione del software. L’intera strut- tura della Clean Architecture gira intorno ad un’unica regola, chiamata The Dependency Rule, la quale afferma che le dipendenze vanno solo verso l’interno, ovvero le unit`a pi`u interne non hanno alcuna consapevolezza dell’esistenza di quelle pi`u esterne. In altre parole, tutto ci`o che `e dichiarato esternamente non pu`o essere menzionato pi`u internamente, proprio perch´e non ne pu`o essere a conoscenza [21]. Essendo ogni componente Software indipendente dagli altri, il codice risulta molto pi`u riusabile, estremamente testabile, flessibile e di facile gestione, cio`e non particolarmente sensibile ai cambiamenti.

Un esempio di componente `e quello dei Framework: avere un Sofware in- dipendente dalle librerie usate costituisce un vantaggio enorme, soprattutto per quanto concerne le scelte future ed i cambiamenti da apportare per qual- siasi motivo (esempio:“questa libreria non `e pi`u mantenuta dalla Comunit`a, occorre sostituirla”). L’indipendenza dal Database `e anch’essa fondamentale: molte Software house stanno migrando verso soluzioni NoSql come MongoDB; il passaggio `e sicuramente meno tedioso se il resto del proprio sistema `e indipen- dente dalla base dati utilizzata. Anche una UI pu`o essere cambiata facilmente, si pu`o passare da una Desktop based UI ad una Web UI senza dover cambiare le business rules.

Andando ad esplorare pi`u in dettaglio gli aspetti salienti della Clean Ar- chitecture, ci`o che troviamo nel nucleo centrale sono le Entities, considerate come business objects o anche definite business model dell’applicazione. Le Entities incapsulano tutte le regole di business, sono rappresentate da oggetti con dei metodi definiti al loro interno o possono essere un set di strutture dati e funzioni, come ad esempio una classe Studente, Impiegato, o Stipendio. Es- sendo parte del nucleo, il loro stato rimane sempre lo stesso, sono gli oggetti meno soggetti ad un cambiamento: se nel sistema si cambia la veste grafica o si implementa un nuovo algoritmo di Sicurezza, questo non andr`a a modificare il layer delle Entities; la classe Studente rimarr`a la stessa. Al contrario, se viene cambiato un metodo definito in un Entity, tutto il contesto esterno ne risente. Salendo di livello, troviamo gli Use Cases, nei quali vengono definite le Business rules dell’applicazione, ovvero le azioni che l’applicativo `e destinato a compiere, i comportamenti che deve avere: la lista di Clienti deve essere or- dinata per data di inserimento? cosa succede se un pagamento viene avviato? Come si comporta l’oggetto Docente se Studente non passa l’esame per tre volte consecutivamente? ecc. Questo layer ha un’interazione forte con le En- tities, dialoga tramite le cosiddette Boudaries, delle interfacce che permettono la comunicazione tra i livelli e che in questo caso possono consentire agli Use Cases di recuperare i dati necessari forniti dagli Entities e gestirli. Robert Ce-

cil Martin, comunemente conosciuto con il nome di “Uncle Bob”, durante una conferenza NDC tenuta a Londra nel 2013, soprannomina questi Use Cases co- me Interactors, definendoli come “the choreographers of the Entities”. Questo nome verr`a utilizzato nelle implementazioni future che si basano sulla Clean Architecture, come nel caso di Viper. Un cambiamento in questo layer non sti- moler`a alcun cambiamento su quello pi`u interno, tuttavia possiamo aspettarci ad esempio che venga cambiato lo stato dell’interfaccia utente.

A fare da tramite tra la business logic ed il layer pi`u esterno, costituito da entit`a come un Database, un Web Service o una GUI, vengono in soccor- so gli Interface Adapters. Sono delle interfacce di supporto che si occupano di convertire il dato dal formato pi`u conveniente per l’Interactor (che general- mente corrisponde all’oggetto dell’Entity) in un formato pi`u adatto ad esempio ad una visualizzazione su schermo. Se ad esempio si fa uso di Hibernate per comunicare con il proprio Database, questo `e il posto giusto dove gestirne le classi. Nessuna parte del codice di questo layer `e a conoscenza di come sia fatta la parte grafica o la struttura di un Database. Non fa altro che preoccuparsi di manipolare i dati per non demandare il lavoro ad altri componenti. Nei casi applicativi in cui il destinatario a cui demandare gli oggetti “trasformati” sia un’interfaccia grafica visualizzabile all’utente, possiamo trovare in questo layer molte similitudini con il Pattern MVP (Model-View-Presenter). Per fare un paragone, il Model in questo caso sar`a l’Interactor, la business logic del- l’applicazione, mentre il Presenter `e l’insieme di classi che si occupa di rendere pi`u fruibili alla View i dati provenienti dall’Interactor. Il livello pi`u esterno, al quale si `e voluto dare il nome Framework & Drivers, `e generalmente conside- rato come un dettaglio, in quanto non `e visto come la parte del software pi`u onerosa in termini di scrittura del codice. Come gi`a accennato, questo livello pu`o essere costituito da un Web Framework, o da una GUI, una base di dati, un collegamento con un device fisico (come ad esempio un iBeacon) e cos`ı via. La Clean Architecture non non ha un pattern rigido, nessuna regola vieta di aggiungere dei cerchi, l’importante `e applicare sempre la regola della Dipen- denza. Come si `e potuto notare, grazie a questa regola ogni parte svolge un compito ben specifico e definito. Questo porta ai vantaggi gi`a citati e favorisce lo sviluppo in ambienti molto dinamici e in continua evoluzione come quello del Mobile.