Pourquoi je pense que les débutants devraient apprendre la clean architecture

Quand j'ai commencé à coder en .NET, mon seul objectif était de faire fonctionner les choses. Je balançais mon database context directement dans mes controllers d'API, j'écrivais des vérifications de validation juste à côté de mes queries SQL, et je déversais la moitié de ma logique dans Program.cs. Ça marchait. L'app tournait, le JSON revenait, et j'avais l'impression de savoir ce que je faisais.

Puis est venue la première fois où j'ai dû changer quelque chose.

J'ai essayé de remplacer une bibliothèque de database et de mettre à jour une règle métier le même jour. La moitié de mes endpoints a cassé. Un ajustement dans un calcul de commande a d'une manière ou d'une autre affecté ma logique d'inscription utilisateur. Je passais l'essentiel de mon temps à démêler du code que j'avais écrit deux semaines plus tôt au lieu d'en écrire du nouveau.

Ce bazar est ce qui m'a poussé à me pencher sur la clean architecture.

Au début, ça avait l'air intimidant. Tout le monde qui en parlait avait l'air de lire un manuel enterprise, en balançant des termes comme dependency inversion et domain-driven design. Mais dès que j'ai vraiment commencé à découper mes solutions .NET en couches propres, quelque chose a fait tilt.

Comment je la structure vraiment maintenant

Quand je démarre un projet, je mets en place d'abord la couche Domain avec des classes C# pures, pas d'Entity Framework, pas de HTTP, pas de packages tiers, juste la business logic toute seule. Puis la couche Application gère les vrais cas d'usage, en définissant des interfaces pour ce dont elle a besoin, quelque chose comme « récupérer un utilisateur » ou « envoyer un email », sans se soucier encore de comment ces choses se passent vraiment.

C'est seulement une fois que c'est en place que je touche à EF Core ou ASP.NET. Les database contexts et les API externes vont dans Infrastructure, et les Minimal API ou les Controllers vont dans Presentation.

Ce qui a vraiment changé au quotidien

Les principes SOLID ont arrêté d'être des réponses d'entretien et sont devenus la façon dont mes dossiers de projet sont déjà organisés, pas quelque chose que je dois penser à appliquer par-dessus.

Le testing a arrêté d'être un casse-tête. Les règles métier qui ne savent rien d'un database peuvent être testées avec xUnit en quelques secondes, pas de database en mémoire, pas de mocks élaborés, juste la logique toute seule.

Le lock-in de stack technique a arrêté de m'inquiéter. Si je remplace SQL Server ou change de provider d'email, seul Infrastructure change. L'application cœur ne s'en aperçoit même pas.

Où je garde encore les choses simples

Il y a encore des moments où sauter tout ça. Une app CRUD basique qui pourrait tenir en quelques fichiers n'a pas besoin de quatre projets séparés. Mais traverser ce changement a changé ma façon de penser le code en général : passer du fait de balancer de la syntaxe contre le mur jusqu'à ce que ça marche, à construire quelque chose pensé pour vraiment tenir quand j'ai besoin de le changer plus tard.