Oggi nel mondo del software è molto diffuso l’uso delle cosiddette Clean Architecture. Vengono chiamate così perché si basano tutte sullo stesso principio di progettazione del software: la separazione delle responsabilità. Una delle più conosciute è l’architettura esagonale, ma ce ne sono molte altre. In questa occasione, ti forniamo le informazioni necessarie per capire quando e perché utilizzare Clean Architecture.
Parti o livelli di Clean Architecture
– Infrastruttura: sono gli elementi esterni con cui l’applicazione comunica, sia in input che in output:
- Punti di ingresso: un’API con REST o GraphQL, messaggistica con RabbitMQ o tramite linea di comando, ecc.
- Punti di uscita: un database relazionale con PostgreSQL, non relazionale con MongoDB, o anche l’invio di messaggi con RabbitMQ, ecc.
– Application/Use Cases: si tratta della valutazione delle regole di business e della presa di decisioni. Contengono le regole che danno senso all’applicazione. I casi d’uso guidano il flusso verso le entità e le orchestrano per soddisfare le esigenze del business.
– Domain: risponde al modello di dati dell’applicazione, ai servizi di dominio, alle interfacce, ecc. Le entità sono i modelli definiti che interagiscono nel sistema; devono essere sufficientemente astratte da poter essere utilizzate da diverse applicazioni nel contesto del business.
Principi di Clean Architecture
1. Indipendente da qualsiasi framework
L’architettura pulita dovrebbe poter essere applicata a qualsiasi sistema, indipendentemente dal linguaggio di programmazione o dalle librerie utilizzate. Le diverse componenti devono essere così ben separate che possano funzionare autonomamente, senza dipendere da elementi esterni.
2. Testabilità
Più una funzione, una classe o un modulo è puro (ovvero senza effetti collaterali), più facile sarà prevedere i risultati ottenuti. Ogni modulo, che sia l’interfaccia utente, il database, la connessione a un’API REST, ecc., dovrebbe essere testabile individualmente.
3. Indipendente dall'interfaccia utente (UI)
Uno dei componenti che subisce frequenti cambiamenti è l’interfaccia utente. La UI dovrebbe poter cambiare senza influire sull’intero sistema. Inoltre, questa componente dovrebbe essere così indipendente da poter essere smontata e sostituita con un’altra. Ad esempio, è possibile passare da un’interfaccia utente mobile a una console.
4. Indipendente dal database
Come nel punto precedente, anche questa componente dovrebbe essere modulare e consentire l’aggiunta di molteplici fonti di dati, anche dello stesso tipo. Ad esempio, gestire più database come MySQL, PostgreSQL, Redis, ecc.
5. Indipendente da qualsiasi elemento esterno
Se in un punto del sistema è necessaria l’utilizzo di una libreria, un altro sistema o qualsiasi altro elemento esterno, dovrebbe essere facile da assemblare e modularizzare. In effetti, per il sistema, questa componente esterna dovrebbe essere trasparente.
Vantaggi dell'utilizzo di Clean Architecture
Questa tecnologia è ideale per i progetti a lungo termine. Se hai bisogno che il tuo progetto duri nel tempo, che sia facilmente testabile e tollerante ai cambiamenti, sfrutta i vantaggi di questa architettura:
1- Implementazione immediata
Puoi implementarla con qualsiasi linguaggio di programmazione, tra cui Java, .Net, Php, Node.js, ecc.
2- Focalizzazione sul dominio dell'applicazione
Ciò significa che il focus principale del progetto viene posto sul nucleo e sulla logica del dominio.
3- Possibilità di apportare cambiamenti
Questa architettura consente di apportare modifiche significative all’applicazione senza grandi impatti:
- Puoi cambiare il framework utilizzato, se necessario, poiché tutto è disaccoppiato.
- Puoi cambiare o aggiungere un database se necessario.
4- Test attesi
Hai la possibilità di testare in modo rapido e facile. Puoi eseguire test unitari su ciascuno dei livelli e test di integrazione tra i diversi livelli, sostituendoli con oggetti temporanei che simulano il loro comportamento in modo semplice.
5- Risultato ottimale
Creerai un prodotto solido, di qualità e scalabile.
Tuttavia, se desideri realizzare un prodotto minimale funzionante (PMV), ti consigliamo di evitare questo tipo di architettura. Richiederà troppo tempo, sforzo e costi che potrebbero essere evitati. Se il tuo PMV ha successo e richiede uno sviluppo più avanzato e potente, Clean Architecture può sicuramente aiutarti.
Clean Architecture e Domain-Driven Design (DDD)
Le Clean Architecture si adattano molto bene all’approccio di Domain-Driven Design (DDD). Ma qual è la relazione tra queste architetture pulite e DDD?
Essendo un’architettura che favorisce il fatto che il nostro dominio sia il nucleo di tutti i livelli e che non sia accoppiato a nulla di esterno, funzionano perfettamente insieme. Si potrebbe dire che DDD si basa su un’architettura pulita come pilastro centrale in termini di architettura.
Conclusioni su Clean Architecture
Ora che conosci quando e perché utilizzare una Clean Architecture, sarai in grado di stabilire se è la migliore opzione per il tuo progetto. Presso MyTaskPanel Consulting, disponiamo di professionisti qualificati che hanno esperienza in questo campo e possono essere il supporto tecnologico di cui hai bisogno. Contattaci senza impegno qui.
