Quando si parla di Clean Architecture, i primi concetti che vengono in mente sono i principi SOLID.

Non è un caso: questi principi, con il loro approccio metodico e i loro nomi altisonanti, sono spesso i protagonisti delle discussioni sulla progettazione software.

Ma la Clean Architecture offre molto di più! C’è un intero set di regole meno conosciute, ma altrettanto fondamentali: i Principi di Design dei Componenti (Component Design Principles).

Questi principi non si concentrano sulla progettazione delle singole classi, ma sull’organizzazione dei componenti del sistema, cioè quelle unità logiche che costituiscono le fondamenta di un’applicazione scalabile, manutenibile e stabile.

Perché è importante parlare dei Principi di Design dei Componenti?

In un mondo in cui le applicazioni software diventano sempre più complesse, il rischio di creare un sistema rigido e fragile cresce esponenzialmente.

Ogni modifica potrebbe propagarsi in modi imprevedibili, causando regressioni, bug e tempi di sviluppo insostenibili.

I Principi di Design dei Componenti offrono una guida per:

• Organizzare il sistema: I componenti non sono semplicemente pezzi di codice, ma entità con responsabilità specifiche e ben definite.
• Ridurre la fragilità: Minimizzano l’accoppiamento tra le parti, rendendo il sistema più resistente ai cambiamenti.
• Favorire la modularità: Consentono di creare componenti riutilizzabili e indipendenti, migliorando la manutenibilità.
• Mantenere la stabilità: Aiutano a progettare componenti che non si rompono al primo cambiamento e che evitano il caos delle dipendenze circolari.

Insomma, se i principi SOLID sono indispensabili per progettare classi robuste, i component design principles sono la chiave per progettare sistemi scalabili e resilienti.

Cos’è un Componente?

Nella Clean Architecture, un componente è una unità minima di deploy, come una libreria (.dll) o un package distribuito (es. NuGet).

Ogni componente è progettato per:

• Incapsulare una responsabilità specifica all’interno del sistema.
• Essere modulare, testabile e facilmente rilasciabile.
• Ridurre l’accoppiamento con altri componenti, favorendo un’architettura scalabile e manutenibile.

Un componente rappresenta una parte del sistema che può essere sviluppata, verificata e rilasciata in modo indipendente, anche se in alcuni contesti potrebbe essere necessario un deploy coordinato.

Nota: I componenti non sono solo unità di codice, ma artefatti concreti che rappresentano il software distribuito.

I Component Design Principles

Il Design dei Componenti è un aspetto fondamentale della Clean Architecture, che si concentra sull’organizzazione delle unità di deploy all’interno di un sistema software.

I Component Design Principles guidano il design in modo che i componenti siano:

• Modulari: Ogni componente ha confini chiari (boundaries) e responsabilità ben definite, senza sovrapposizioni con altri.
• Manutenibili: È possibile intervenire su un componente senza introdurre errori nel resto del sistema.
• Scalabili: I componenti possono essere estesi o sostituiti senza compromettere l’integrità dell’intera applicazione.
• Rilasciabili: Ogni componente può essere distribuito come unità autonoma, riducendo l’impatto delle modifiche.

Mentre i principi SOLID si concentrano sul design delle singole classi e delle loro relazioni, i Component Design Principles si occupano dell’organizzazione delle relazioni tra componenti più grandi del sistema.

L’obiettivo è garantire che il sistema sia:

• Facile da evolvere: I cambiamenti richiesti dai requisiti devono essere localizzati.
• Resistente ai cambiamenti: Modifiche in un componente non devono propagarsi inutilmente.
• Stabile nel tempo: I componenti più critici devono essere protetti da cambiamenti frequenti.

I Component Design Principles sono suddivisi in due categorie principali, che riflettono aspetti diversi della progettazione:

• Principi di coesione dei componenti: La coesione riguarda quali classi o moduli devono stare insieme all’interno dello stesso componente. L’obiettivo è progettare componenti con una responsabilità ben definita, evitando confusione e fragilità interna.
• Principi di accoppiamento dei componenti: L’accoppiamento riguarda le relazioni tra i componenti e come essi interagiscono. Questi principi mirano a minimizzare le dipendenze fragili o cicliche, rendendo il sistema stabile e scalabile.

Facciamo un esempio

In un sistema per la gestione degli ordini, possiamo organizzare i componenti del microservizio Ordini come segue, ciascuno con responsabilità ben definite:

OrderApi

Espone le funzionalità dell’applicazione tramite un’interfaccia REST. Questo componente è un adapter che traduce le richieste HTTP in comandi e queries da passare all’Application Component, per l’esecuzione dello use case associato.

Ruolo: Punto di ingresso delle richieste, completamente isolato dai dettagli di implementazione

OrderApplication

Contiene i casi d’uso (interactors) dell’applicazione.

Coordina le operazioni richieste senza gestire direttamente i dettagli di persistenza o infrastruttura.

Include le interfacce necessarie per definire i contratti tra application component e gli altri componenti.

Grazie al principio di Inversione delle Dipendenze, saranno gli altri componenti a referenziare OrderApplication per implementare le interfacce richieste.

Ruolo: Rappresenta il nucleo dell’applicazione, fornendo tutti i casi d’uso ad alto livello, senza preoccuparsi dei dettagli implementativi

OrderDomain

Contiene il domain model applicativo (entities e logica di business).

È il nucleo più astratto dell’applicazione e non dipende da dettagli implementativi.

Rappresenta le regole e le validazioni centrali del sistema e le regole del dominio di business.

Ruolo: Stabilire le fondamenta della logica di business

OrderPersistence

Gestisce la persistenza dei dati.

Legge e scrive gli ordini nel database e, più in generale, si occupa concretamente di tutte le operazioni di accesso al database.

Implementa i contratti definiti dall’OrderApplication in fatto di persistenza dei dati.

Ruolo: Fornire un accesso astratto ai dati senza esporre dettagli tecnici agli altri componenti

OrderInfrastructure

Contiene i servizi infrastrutturali, come log, configurazioni o integrazioni con API esterne.

Gestisce dipendenze tecnologiche e dettagli implementativi.

Implementa i contratti definiti nell’OrderApplication.

Ruolo: Garantire che i dettagli infrastrutturali non inquinino l’application component con dipendenze esterne o responsabilità di basso livello

Principi di coesione dei componenti

I principi di coesione definiscono come organizzare il contenuto interno di un componente, aiutando a decidere quali classi o moduli devono convivere al suo interno per garantirne chiarezza e manutenibilità.

Reuse/Release Equivalence Principle (REP)

Una granularità di riutilizzo deve coincidere con una granularità di rilascio

Il Reuse/Release Equivalence Principle (REP) afferma che l’unità di riutilizzo deve coincidere con l’unità di rilascio.

Questo principio sottolinea che, per riutilizzare un componente in modo efficace, quel componente deve essere rilasciato (o distribuibile) come un’entità autonoma e gestita.

In altre parole, un componente:

• Deve essere progettato per essere riutilizzabile.
• Deve essere rilasciato formalmente con un processo che includa versionamento, gestione delle dipendenze e controllo di qualità.

Quando vogliamo rendere un componente riutilizzabile in più parti di un sistema o in sistemi diversi, non possiamo semplicemente “copiarlo e incollarlo”.

Il componente deve essere:

• Distribuito come unità autonoma: Ad esempio, sotto forma di una libreria (.dll o package NuGet) o un altro artefatto rilasciabile.
• Versionato: Ogni modifica deve essere tracciata e documentata, per garantire che chi utilizza il componente sappia cosa aspettarsi.
• Stabile e ben testato: Un componente riutilizzabile non può contenere bug o comportamenti imprevisti, perché questo potrebbe causare problemi nei sistemi che lo utilizzano.

Il principio REP garantisce che:

• I componenti riutilizzabili siano affidabili: Ogni versione del componente viene formalmente rilasciata, testata e validata.
• Il riutilizzo sia gestito in modo professionale: Con versionamento e distribuzione centralizzata, i team possono integrare i componenti senza duplicare il codice.
• Le dipendenze siano chiare: I sistemi che utilizzano un componente sanno esattamente quale versione stanno utilizzando e quali sono i requisiti.

Common Closure Principle (CCP)

Le classi che cambiano per gli stessi motivi e nello stesso momento dovrebbero essere nello stesso componente.

Il Common Closure Principle (CCP) si basa sul concetto di chiusura comune, che indica che un componente dovrebbe raggruppare tutte le classi che potrebbero essere modificate insieme.

Questo principio aiuta a ridurre il rischio di propagazione delle modifiche e limita il numero di componenti che devono essere aggiornati per rispondere a un cambiamento nei requisiti.

L’idea centrale è che:

• Le classi che condividono motivazioni di cambiamento simili sono coese.
• Raggrupparle nello stesso componente riduce l’accoppiamento esterno e semplifica la manutenzione del sistema.

Il CCP mira a garantire che un cambiamento in un requisito non si traduca in modifiche distribuite su più componenti. Così facendo, riduce:

• La fragilità del sistema, perché le modifiche sono contenute in un unico componente.
• Il costo della manutenzione, perché meno componenti devono essere aggiornati.
• Il rischio di rotture impreviste, poiché le modifiche rimangono localizzate.

Errori comuni:

1. Raggruppare classi senza motivo: Non tutte le classi che collaborano devono essere nello stesso componente; solo quelle che cambiano insieme.
2. Sottovalutare i confini di dominio: Raggruppare classi con motivazioni di cambiamento diverse può portare a componenti troppo grandi e difficili da gestire.

Common Reuse Principle (CRP)

Le classi che vengono riutilizzate insieme dovrebbero essere nello stesso componente

Il Common Reuse Principle (CRP) stabilisce che un componente dovrebbe contenere solo le classi che vengono riutilizzate insieme.

Questo principio aiuta a minimizzare le dipendenze inutili e a mantenere i componenti più snelli e focalizzati sulla loro responsabilità.

L’idea principale è evitare che un consumatore di un componente debba dipendere da elementi che non utilizzerà mai.

Questo riduce l’accoppiamento accidentale, cioè la dipendenza da funzionalità non rilevanti per chi utilizza il componente.

Il CRP mira a:

1. Ridurre le dipendenze inutili: Evitando che un componente includa classi o moduli non necessari per tutti i suoi utilizzatori.
2. Facilitare il riutilizzo mirato: Garantendo che chi dipende da un componente ottenga solo ciò di cui ha bisogno.
3. Mantenere i componenti focalizzati: Limitando le responsabilità di ciascun componente.

Errori comuni:

1. Accorpamento forzato: Raggruppare classi non strettamente correlate nello stesso componente per convenienza iniziale, creando dipendenze inutili.
2. Separazione eccessiva: Dividere componenti in modo troppo fine, aumentando la complessità senza reali benefici.
3. Ignorare il contesto di riutilizzo: Non analizzare attentamente quali classi sono effettivamente riutilizzate insieme.

Diagramma di tensione

Il Diagramma di tensione è uno strumento introdotto per rappresentare visivamente il compromesso tra i tre Principi di coesione dei componenti:

1. Reuse/Release Equivalence Principle (REP)
2. Common Closure Principle (CCP)
3. Common Reuse Principle (CRP)

Questi principi, pur essendo fondamentali per un buon design, non possono sempre essere applicati simultaneamente senza entrare in conflitto.

Il diagramma di tensione aiuta a capire e bilanciare queste forze opposte.

Nel diagramma:

• Ogni principio rappresenta un vertice di un triangolo, con il sistema che si posiziona da qualche parte all’interno del triangolo.
• Le tensioni sorgono quando si cerca di applicare uno o più principi in modo eccessivo, a discapito degli altri.

Tensioni tra i principi

• REP vs CCP: Il REP suggerisce di creare componenti più grandi per aumentare il riutilizzo, ma ciò potrebbe violare il CCP, che richiede componenti piccoli e chiusi per responsabilità comuni.
• CCP vs CRP: Il CCP incoraggia il raggruppamento di classi che cambiano insieme, ma questo potrebbe portare a includere classi che non vengono sempre riutilizzate insieme, violando il CRP.
• CRP vs REP: Perseguire il CRP potrebbe portarti a creare componenti molto specifici, riducendo il riutilizzo e complicando la gestione del rilascio, in contrasto con il REP.

Il diagramma di tensione non è uno strumento per “risolvere” i conflitti, ma per bilanciare i principi in base alle esigenze del progetto.

Ogni sistema si posizionerà in un punto diverso all’interno del triangolo in base a:

• La necessità di riutilizzo (REP).
• La frequenza e il tipo di modifiche attese (CCP).
• Il desiderio di minimizzare dipendenze inutili (CRP).

Principi di accoppiamento dei componenti

I principi di accoppiamento definiscono come i componenti dovrebbero relazionarsi tra loro, stabilendo regole per minimizzare le dipendenze fragili e le relazioni circolari.

L’obiettivo è garantire che i cambiamenti in un componente non abbiano impatti indesiderati sugli altri, mantenendo il sistema stabile e facilmente scalabile.

Acyclic Dependencies Principle (ADP)

Le dipendenze tra i componenti devono formare un grafo aciclico

L’Acyclic Dependencies Principle (ADP) stabilisce che i componenti di un sistema non devono mai dipendere in modo circolare.

In altre parole, se i componenti A, B e C sono collegati, non dovrebbe mai accadere che:

• A dipenda da B
• B dipenda da C
• e C dipenda nuovamente da A

Questa situazione crea un ciclo che può rendere il sistema:

• Difficile da comprendere: Le relazioni tra i componenti diventano confuse.
• Fragile: Una modifica in un componente potrebbe propagarsi inaspettatamente attraverso il ciclo.
• Impossibile da compilare: In alcuni linguaggi, come C#, le dipendenze circolari impediscono al codice di essere compilato.

L’ADP suggerisce di progettare i componenti in modo che le loro dipendenze formino un grafo diretto aciclico (DAG), dove ogni dipendenza ha una direzione chiara e non ci sono cicli.

L’ADP ha lo scopo di:

1. Evitare complessità: Eliminare i cicli rende le dipendenze più semplici da analizzare e mantenere.
2. Facilitare la manutenibilità: Ogni componente può essere modificato o rilasciato senza il rischio di propagare cambiamenti indesiderati.
3. Migliorare il testing: Le dipendenze lineari semplificano l’isolamento dei componenti per i test.

Errori comuni:

1. Trascurare i cicli indiretti: Anche se un ciclo non è evidente, dipendenze indirette possono creare problemi (es. A → B → C → A).
2. Spezzare un ciclo in modo errato: Introdurre troppi componenti intermedi può complicare il design. La soluzione deve essere semplice e mirata.
3. Non monitorare le dipendenze: Senza strumenti o revisioni regolari, i cicli possono introdursi nel sistema col tempo.

Stable Dependencies Principle (SDP)

Un componente deve dipendere solo da componenti più stabili di lui

Il Stable Dependencies Principle (SDP) stabilisce che un componente dovrebbe dipendere solo da altri componenti che sono più stabili di lui stesso.

Questo principio aiuta a ridurre il rischio di rotture o modifiche impreviste che potrebbero propagarsi attraverso il sistema.

La stabilità di un componente è una misura di quanto sia difficile modificarlo.

Più un componente è referenziato da altri, più è stabile, perché le modifiche in quel componente richiedono di aggiornare tutti i componenti che lo utilizzano.

La stabilità di un componente si calcola attraverso due metriche:

• Fan-in (dipendenze in ingresso): Il numero di componenti che dipendono da un determinato componente.
• Fan-out (dipendenze in uscita): Il numero di componenti da cui un determinato componente dipende.

La formula per calcolare la stabilità (I) di un componente è:

• I = 0: Componente completamente stabile (nessuna dipendenza da altri)
• I = 1: Componente completamente instabile (dipende solo da altri componenti)

Stable Abstractions Principle (SAP)

Un componente stabile dovrebbe essere anche astratto, in modo da consentire la sua estensibilità

Il Stable Abstractions Principle (SAP) afferma che un componente che è stabile (cioè ha un alto fan-in e un basso fan-out) dovrebbe anche essere astratto.

Questo principio permette che un componente stabile possa evolversi senza richiedere modifiche dirette, perché le sue funzionalità sono definite tramite interfacce o classi astratte che altri componenti possono implementare o estendere.

Un componente stabile ma concreto rischia di diventare un collo di bottiglia per l’evoluzione del sistema: ogni modifica al suo interno richiederebbe il coordinamento con tutti i componenti che lo utilizzano.

Relazione tra stabilità e astrazione:

• Componenti stabili (alto fan-in): Sono referenziati da molti altri componenti, quindi qualsiasi modifica potrebbe avere impatti significativi.
• Componenti astratti: Forniscono contratti o interfacce che possono essere estesi senza dover modificare il componente stesso.

Il SAP combina questi due aspetti: un componente stabile dovrebbe essere principalmente un contenitore di astrazioni, delegando l’implementazione concreta a componenti meno stabili.

Come si misura?

Il SAP introduce un concetto chiamato Indice di astrazione (A) per valutare quanto un componente sia astratto rispetto alla sua stabilità:

• A=1: Il componente è completamente astratto
• A=0: Il componente è completamente concreto

Idealmente, per rispettare il SAP, un componente con stabilità (I) vicino a 0 (molto stabile) dovrebbe avere un valore di astrazione (A) vicino a 1.

SAP ha lo scopo di:

• Evoluzione senza rotture: I componenti stabili sono difficili da modificare direttamente, ma se sono astratti, è possibile estenderli senza rompere il sistema.
• Flessibilità: I contratti astratti consentono di aggiungere nuove funzionalità o implementazioni senza dover riscrivere i componenti esistenti.
• Manutenibilità: Separare le astrazioni dalle implementazioni semplifica il testing e l’integrazione.

Errori comuni:

• Componenti stabili ma concreti: Questi diventano difficili da modificare, perché ogni cambiamento richiede l’aggiornamento di tutti i componenti che li utilizzano.
• Componenti instabili ma astratti: Non rispettano il SAP e aggiungono complessità senza reale beneficio.
• Mancata separazione tra astrazione e implementazione: Mescolare contratti astratti e implementazioni concrete in un unico componente viola il principio.

Il Diagramma Stabilità-Astrazione

Il diagramma stabilità-astrazione è uno strumento visuale che aiuta a valutare i componenti di un sistema software in base a due dimensioni fondamentali: stabilità (I) e astrazione (A).

Il suo scopo è garantire che i componenti siano progettati in modo bilanciato, rispettando i principi di accoppiamento dei componenti.

• Asse X (Stabilità I): Misura la difficoltà di modificare un componente. Più un componente è stabile, più altri dipendono da esso.
• Asse Y (Astrazione A): Indica quanto un componente sia astratto o concreto.

La sequenza principale è la linea diagonale che collega (0,1) a (1,0).

I componenti ideali si trovano lungo questa linea, bilanciando stabilità e astrazione.

Le quattro zone del diagramma

1. Zona di dolore (I=0,A=0): Componenti stabili ma concreti. Questi sono difficili da modificare perché molti altri componenti dipendono da loro e non hanno astrazioni per estenderli.
2. Zona di inutilità (I=1,A=1): Componenti instabili e astratti. Forniscono astrazioni che nessuno utilizza, rendendoli inutili.
3. Zona di esclusione (I=1,A=0): Componenti instabili e concreti. Sono specifici e difficilmente riutilizzabili, con scarso valore per il sistema.
4. Sequenza principale (I=0,A=1→I=1,A=0): Il percorso ideale. I componenti stabili dovrebbero essere astratti, mentre quelli instabili possono essere concreti.

Calcolo della distanza dalla sequenza principale

La distanza dalla sequenza principale (DDD) misura quanto un componente si allontani dall’equilibrio ideale:

• D=0: Il componente è perfettamente bilanciato.
• D>0: Più grande è la distanza, meno il componente rispetta il bilanciamento tra stabilità e astrazione.

Conclusione

I Principi di Design dei Componenti offrono una guida fondamentale per organizzare un sistema software in modo che sia modulare, scalabile e manutenibile.

Questi principi non solo aiutano a ridurre la fragilità e l’accoppiamento, ma forniscono anche un quadro per garantire che ogni componente del sistema sia progettato con responsabilità chiare e confini ben definiti.

• I principi di coesione ci insegnano a raggruppare le classi che cambiano insieme, minimizzando i rischi di modifiche indesiderate.
• I principi di accoppiamento ci aiutano a mantenere le relazioni tra i componenti semplici e stabili, riducendo la complessità del sistema.

Grazie al diagramma stabilità-astrazione, possiamo visualizzare e misurare l’equilibrio tra stabilità e astrazione, evitando zone problematiche e migliorando la qualità complessiva del design.

Adottare i Principi di Design dei Componenti è un viaggio, non un punto di arrivo.

L’obiettivo non è creare una soluzione perfetta, ma migliorare progressivamente l’organizzazione dei componenti, riducendo fragilità e accoppiamento.

Ma la teoria, da sola, non basta: ogni principio deve essere compreso nel dettaglio per poter essere applicato correttamente.

Data la complessità e l’importanza di questi argomenti, pubblicheremo una serie di articoli dedicati a ciascun principio, con esempi pratici e approfondimenti.

Quale principio ti incuriosisce di più? Hai mai avuto difficoltà nell’organizzare i componenti di un sistema?