Architettura software .NET per smettere di rincorrere il codice e tornare a governarlo

I design pattern non sono ricette da copiare: sono risposte a problemi reali

Ogni volta che vedo un progetto con classi chiamate FactoryManagerHelperService ho la certezza di trovarmi davanti a un uso del pattern sbagliato: qualcuno ha imparato il nome senza capire il problema che quel pattern dovrebbe risolvere.

Un design pattern è una soluzione consolidata a un problema che si ripete.

Il Repository non esiste per soddisfare un requisito architetturale astratto: esiste perché separare la logica di dominio dall'accesso ai dati rende il codice testabile, sostituibile e leggibile da chiunque conosca il pattern.

Se nel tuo progetto nessuno sa spiegare perché esiste un certo layer, quel layer probabilmente non dovrebbe esistere.

Il mio approccio ai pattern è pragmatico.

Prima capisco quale problema c'è, poi valuto se un pattern noto lo risolve meglio di una soluzione ad hoc.

Molto spesso la risposta è sì: non perché i pattern siano magia, ma perché rappresentano il risultato di decenni di errori che altri hanno già fatto.

Questa categoria esiste per aiutarti a capire i pattern come strumenti di pensiero, non come checklist.

Quando sai perché Repository, CQRS, Mediator o Specification esistono, smetti di applicarli meccanicamente e inizi a usarli dove portano valore reale.

Quando l'architettura diventa un problema economico

L'architettura software non è un tema accademico.

È un problema economico che si manifesta nel tempo.

Un sistema progettato male non crolla il giorno uno.

Regge.

Poi rallenta.

Poi ogni modifica richiede il doppio del tempo.

Poi le persone chiave diventano insostituibili perché solo loro conoscono i punti oscuri del codice.

Poi il testing diventa impossibile.

Poi arriva il refactoring di emergenza, che di solito costa cinque volte quello che sarebbe costato fare le cose bene all'inizio.

Quando un team mi chiede aiuto su un sistema in difficoltà, quasi sempre trovo le stesse radici: accoppiamento eccessivo tra componenti, assenza di confini chiari tra dominio e infrastruttura, logica di business dispersa ovunque, nessuna coerenza nei nomi.

Sono tutti sintomi che indicano l'assenza di un modello architetturale consapevole.

I pattern non eliminano la complessità del dominio.

La rendono governabile.

E la differenza tra complessità governabile e complessità caotica è spesso la differenza tra un'azienda che riesce a rilasciare e una che ha paura di cambiare qualcosa.

DDD, CQRS e Clean Architecture: quando usarli e quando evitarli

Uno degli errori più costosi che vedo nei team è adottare DDD, CQRS o Clean Architecture perché «si fa così» o perché li hanno visti in un talk su YouTube.

Questi sono pattern ad alta complessità strutturale: portano benefici reali solo quando il dominio li giustifica.

DDD ha senso quando la complessità del sistema sta nel dominio di business, non nell'infrastruttura. Se stai costruendo un sistema di gestione contratti, workflow di approvazione o logica di pricing complessa, DDD ti dà gli strumenti per modellare quel dominio in modo esplicito e condiviso con il business. Se stai costruendo un CRUD con qualche validazione, DDD è overkill.

CQRS ha senso quando i modelli di lettura e scrittura hanno requisiti molto diversi: performance, proiezioni denormalizzate, scalabilità asimmetrica. Se applichi CQRS a un sistema dove lettura e scrittura hanno la stessa semplicità, stai aggiungendo layer senza aggiungere valore.

Clean Architecture ha senso quando vuoi che il dominio non dipenda dall'infrastruttura e che il sistema sia testabile indipendentemente dal database, dal framework o dall'UI. Ma richiede disciplina: senza una comprensione profonda delle dipendenze tra layer, diventa un labirinto di interfacce inutili.

Il principio che uso sempre è: applica la complessità strutturale solo dove la complessità del problema la giustifica.

Il codice semplice che funziona è meglio del codice complesso che segue un pattern.

Come introdurre i pattern in un progetto esistente senza bloccare il team

Nessuno ha il lusso di riscrivere tutto da zero.

I pattern devono entrare nei sistemi esistenti in modo incrementale, senza bloccare le consegne e senza terrorizzare il team.

Il mio approccio è sempre per priorità di rischio e impatto.

Non inizio dal layer più bello da refactorizzare: inizio dal codice che causa più problemi, che nessuno vuole toccare, che rallenta ogni sprint.

Spesso è la logica di business dispersa nei controller, oppure l'accesso diretto al database dappertutto, oppure una classe da tremila righe che fa tutto.

Il primo passo non è introdurre un pattern: è capire dove il codice produce attrito e perché.

Solo dopo si sceglie lo strumento.

A volte basta estrarre un metodo.

A volte serve un Repository.

A volte il problema è un Bounded Context non riconosciuto che mescola responsabilità incompatibili.

Quello che non funziona è imporre un'architettura dall'alto e aspettarsi che il team la rispetti senza capirla.

I pattern si adottano quando il team capisce il problema che risolvono.

La formazione è parte del processo, non un prerequisito separato.

Come leggere gli articoli di questa categoria

Gli articoli che trovi qui non sono tutorial che ti insegnano a implementare un pattern in venti minuti.

Sono analisi di problemi reali, con il ragionamento che porta alla scelta di una certa struttura e le conseguenze che quella scelta produce nel tempo.

Alcuni articoli partono da un sintomo: un sistema che non scala, un test impossibile da scrivere, una funzione che nessuno riesce a modificare senza paura.

Da lì arrivano al pattern che risolve quel problema specifico, spiegando perché funziona e dove smette di funzionare.

Se vuoi usare questa categoria nel modo più efficace, ti consiglio di non leggerla in ordine alfabetico per pattern.

Parti dal sintomo che riconosci nel tuo sistema, trova l'articolo che lo affronta, capisce il ragionamento e poi valuta se il contesto è abbastanza simile da rendere applicabile la stessa soluzione.

I pattern non si copiano.

Si capiscono e si adattano.