Clean Architecture

La Clean Architecture est un principe d'organisation du code qui place les règles métier au centre et repousse à la périphérie tout ce qui est technique — base de données, framework, interface, services externes — afin de pouvoir remplacer ces derniers sans réécrire le métier. Elle a été formalisée par Robert C. Martin et prolonge des idées voisines comme l'architecture hexagonale d'Alistair Cockburn.

L'intuition tient en une phrase : votre logiciel doit pouvoir changer d'ORM, de framework ou de prestataire de paiement comme on change un lave-vaisselle, sans refaire la plomberie de la maison. Dans la plupart des applications, c'est l'inverse qui se produit : le métier est dissous dans le framework, et changer l'un impose de réécrire l'autre.

Comment ça marche

Le code s'organise en couches concentriques. Au centre, les entités portent les règles vraies indépendamment de toute application. Autour, les cas d'usage décrivent les actions du système, une par une : ouvrir un contrat, valider une commande, résilier un abonnement. Puis viennent les adaptateurs — contrôleurs HTTP, implémentations d'accès aux données, clients d'API — et enfin les outils : serveur web, ORM, interface graphique.

Une seule règle gouverne l'ensemble, la règle de dépendance : le code d'une couche interne ne connaît jamais une couche externe. Concrètement, le cas d'usage déclare une interface décrivant ce dont il a besoin — enregistrer un client, envoyer une notification — et une implémentation Doctrine, Eloquent ou autre vient la satisfaire depuis l'extérieur.

À quoi ça sert concrètement

• Tester les règles métier sans base de données ni serveur, donc en quelques secondes
• Changer de prestataire externe ou de couche de persistance sans effet de bord généralisé
• Rendre le système lisible : la liste des cas d'usage décrit l'application mieux qu'un cahier des charges
• Faire travailler plusieurs développeurs sur un même domaine sans collisions permanentes

Les pièges

Le principal est la sur-ingénierie. Appliquée à une application qui ne fait que du CRUD, cette architecture triple le nombre de fichiers sans rien apporter : trois couches pour enregistrer un formulaire de contact relèvent du zèle, pas de la qualité.

Le deuxième est le coût de la conversion entre objets métier et objets de persistance, réel et souvent sous-estimé. Le troisième est le dogmatisme : les schémas circulaires se discutent à l'infini alors que seule compte la direction des dépendances. Le quatrième, enfin, est de l'adopter sans tests automatisés — elle perd alors sa principale justification.

Quand la choisir, quand l'éviter

Elle se justifie quand le domaine est riche et coûteux à se tromper — assurance, santé, logistique, facturation, calculs réglementaires — quand plusieurs interfaces attaquent le même métier, et quand le logiciel doit vivre longtemps. Pour un site éditorial, un MVP ou un back-office, une organisation en services bien nommés suffit largement.