Clean Architecture

Cos'è la Clean Architecture, quali sono i suoi principi cardine e come strutturare un software flessibile, testabile e indipendente da framework o database.

Cos'è la Clean Architecture?

La Clean Architecture è un pattern di progettazione software teorizzato da Robert C. Martin (noto anche come "Uncle Bob") nel 2012. Il suo scopo principale è la separazione degli interessi (Separation of Concerns), consentendo agli sviluppatori di creare sistemi che siano facili da mantenere, altamente testabili e indipendenti da librerie, database o framework di terze parti.

Immagina di costruire una casa in cui puoi cambiare completamente l'impianto idraulico o elettrico senza dover abbattere le pareti portanti. La Clean Architecture offre esattamente questo livello di modularità e disaccoppiamento al tuo codice sorgente.

La Regola della Dipendenza (Dependency Rule)

Il cuore pulsante della Clean Architecture è rappresentato dal diagramma a cerchi concentrici. La regola fondamentale che governa questa struttura è la Dependency Rule:

"I codici sorgenti possono puntare solo verso l'interno. Niente nei cerchi interni può sapere nulla di ciò che si trova nei cerchi esterni."

Ciò significa che le classi, le funzioni o i dati definiti in un cerchio esterno non devono mai essere menzionati dal codice di un cerchio più interno. Ad esempio, la logica di business pura non deve assolutamente sapere se stai usando PostgreSQL o MongoDB, o se la tua interfaccia utente è una pagina web React o un'app mobile Flutter.

I 4 Cerchi (Layer) dell'Architettura

Sebbene sia possibile definire più di quattro livelli a seconda della complessità dell'applicazione, lo schema standard di Uncle Bob ne prevede quattro principali:

1. Entities (Entità)

Le Entità occupano il cerchio più interno e racchiudono le regole di business aziendali più generali e ad alto livello. Un'entità può essere un oggetto con metodi, o un insieme di strutture dati e funzioni. Possono essere utilizzate da molte applicazioni diverse all'interno dell'azienda. Esempio: Un oggetto User con regole per la convalida dell'email o del codice fiscale, che rimangono valide a prescindere dall'applicazione specifica.

2. Use Cases (Casi d'Uso)

Questo layer contiene la logica di business specifica dell'applicazione. I Casi d'Uso orchestrano il flusso di dati da e verso le entità, guidandole a utilizzare le loro regole di business per raggiungere gli obiettivi del caso d'uso. I cambiamenti in questo cerchio non influiscono sulle entità, così come i cambiamenti nei cerchi esterni (como la UI o il database) non influiscono su questo cerchio. Esempio: Un caso d'uso RegisterUser che verifica se l'utente esiste già, crea la password hashata, salva l'utente ed invia un'email di benvenuto.

3. Interface Adapters (Adattatori di Interfaccia)

Gli Adattatori convertono i dati dal formato più comodo per i casi d'uso e le entità a quello più comodo per gli agenti esterni (come database o web). In questo layer risiedono:

I Controllers (che ricevono l'input dell'utente e lo passano ai casi d'uso).
I Presenters e le Views (che formattano i risultati dei casi d'uso per mostrarli all'utente).
I Gateways o Repositories (che definiscono le interfacce per l'accesso ai dati, le quali verranno implementate nel cerchio esterno).

4. Frameworks and Drivers

Il cerchio più esterno è composto da strumenti come il database, i framework web, i server e i dispositivi di input/output. Questo è il luogo in cui risiede tutto il codice "dettaglio". È qui che scriviamo il codice specifico per connetterci a Postgres, per configurare Express.js, o per fare il rendering del DOM. Questo codice deve rimanere il più isolato possibile, fungendo semplicemente da "collante" o plugin per i cerchi interni.

I Vantaggi Principali

Adottare la Clean Architecture porta con sé numerosi benefici a lungo termine:

Indipendenza dai Framework: L'architettura non dipende dall'esistenza di qualche libreria software ricca di funzionalità. Questo ti consente di usare i framework come strumenti, piuttosto che costringere il tuo sistema a conformarsi ai loro vincoli.
Altamente Testabile: La logica di business può essere testata senza la UI, il database, il server web o qualsiasi altro elemento esterno. Puoi scrivere unit test velocissimi e robusti.
Indipendenza dalla UI: La UI può cambiare facilmente senza cambiare il resto del sistema. Un'interfaccia web può essere sostituita con una CLI (Command Line Interface) o un'app mobile senza toccare i casi d'uso.
Indipendenza dal Database: Puoi cambiare DBMS (ad esempio passando da SQL Server o PostgreSQL a MongoDB o DynamoDB) senza che la tua logica di business ne risenta.
Indipendenza da Agenzie Esterne: In generale, le regole di business non sanno nulla del mondo esterno, rendendo l'applicazione resiliente ai cambiamenti tecnologici.

Come Gestire la Comunicazione Verso l'Esterno? (Dependency Inversion)

Ti starai chiedendo: Se i casi d'uso non possono conoscere il database (cerchio esterno), come fanno a salvare i dati?

La risposta risiede nel principio di Inversione della Dipendenza (Dependency Inversion). Nel cerchio interno (Use Cases), definiamo un'interfaccia (un contratto) denominata, ad esempio, UserRepository. Questa interfaccia dichiara metodi come save(user) o findById(id). Nel cerchio esterno (Frameworks & Drivers), scriviamo una classe concreta, come SqlUserRepository, che implementa quell'interfaccia usando le query SQL.

A runtime, grazie all'iniezione delle dipendenze (Dependency Injection), passiamo l'istanza di SqlUserRepository al caso d'uso. In questo modo, la dipendenza del codice punta ancora verso l'interno (il database implementa un'interfaccia definita all'interno), rispettando perfettamente la Dependency Rule!

Conclusione

La Clean Architecture non è una formula magica e richiede indubbiamente una quantità maggiore di codice iniziale (boilerplate), cartelle e file. Tuttavia, per progetti di medie e grandi dimensioni, o per software destinati a durare nel tempo, l'investimento iniziale viene ampiamente ripagato in termini di manutenibilità, flessibilità e facilità di testing.

Se vuoi evitare che il tuo software si trasformi in una "grande palla di fango" (Big Ball of Mud) col passare degli anni, separare le tue regole di business dai dettagli tecnologici è la scelta migliore che tu possa fare.