Perché penso che i principianti dovrebbero imparare la clean architecture

Quando ho iniziato a programmare in .NET, il mio unico obiettivo era far funzionare le cose. Buttavo il mio database context direttamente nei controller della mia API, scrivevo i controlli di validazione proprio accanto alle mie query SQL, e riversavo metà della mia logica in Program.cs. Funzionava. L'app girava, il JSON tornava, e mi sentivo come se sapessi cosa stavo facendo.

Poi è arrivata la prima volta che ho dovuto cambiare qualcosa.

Ho provato a sostituire una libreria di database e aggiornare una regola di business lo stesso giorno. Metà dei miei endpoint si è rotta. Una modifica a un calcolo su un ordine ha in qualche modo colpito la mia logica di registrazione utenti. Passavo la maggior parte del tempo a districare codice che avevo scritto due settimane prima invece di scriverne di nuovo.

Quel casino è ciò che mi ha spinto a guardare la clean architecture.

All'inizio sembrava intimidatoria. Tutti quelli che ne parlavano sembravano leggere da un libro di testo enterprise, buttando lì termini come dependency inversion e domain-driven design. Ma una volta che ho davvero iniziato a spezzare le mie solution .NET in layer appropriati, qualcosa ha fatto click.

Come la struttura davvero adesso

Quando inizio un progetto, configuro prima il layer Domain con classi C# pure, niente Entity Framework, niente HTTP, niente pacchetti di terze parti, solo la business logic da sola. Poi il layer Application gestisce i casi d'uso veri, definendo interfacce per quello di cui ha bisogno, qualcosa come "recupera un utente" o "manda un'email", senza ancora preoccuparsi di come queste cose accadano davvero.

Solo dopo che questo è a posto tocco EF Core o ASP.NET. I database context e le API esterne vanno in Infrastructure, e le Minimal API o i Controller vanno in Presentation.

Cosa è cambiato davvero giorno per giorno

I principi SOLID hanno smesso di essere risposte da colloquio e sono diventati il modo in cui le mie cartelle di progetto sono già impostate, non qualcosa che devo ricordarmi di applicare sopra.

Il testing ha smesso di essere un mal di testa. Le regole di business che non sanno niente di un database possono essere testate con xUnit in pochi secondi, niente database in memoria, niente mock elaborati, solo la logica da sola.

Il lock-in dello stack tecnologico ha smesso di preoccuparmi. Se sostituisco SQL Server o cambio un provider email, cambia solo Infrastructure. L'applicazione core non se ne accorge nemmeno.

Dove continuo a tenerlo semplice

Ci sono ancora momenti in cui saltare tutto questo. Un'app CRUD di base che potrebbe stare in un paio di file non ha bisogno di quattro progetti separati. Ma attraversare questo cambiamento ha cambiato come penso al codice in generale: dal buttare sintassi al muro finché non funziona, al costruire qualcosa pensato per reggere davvero quando devo cambiarlo più avanti.