La Clean Architecture de Robert Martin propose une séparation stricte des responsabilités qui rend les systèmes testables, maintenables et indépendants des frameworks. Retour sur ses principes et son application concrète.
La Clean Architecture, formalisée par Robert C. Martin (Uncle Bob), repose sur un principe fondamental : les dépendances ne pointent que vers l'intérieur. Le domaine métier — les entités et les cas d'usage — est au centre et ne dépend de rien d'externe. Les frameworks, les bases de données, les interfaces utilisateur sont des détails d'implémentation qui entourent ce noyau. On peut changer de framework ou de base de données sans toucher à la logique métier.
En pratique pour une application Spring Boot, cela se traduit par quatre couches distinctes :
- Domain — entités, value objects, règles métier pures. Aucune dépendance vers l'extérieur.
- Application — use cases, ports d'entrée et de sortie. Orchestre le domaine sans connaître l'infrastructure.
- Infrastructure — adaptateurs JPA, clients HTTP, configurations. Implémente les ports sortants définis par l'application.
- Presentation — controllers REST, DTOs. Adapte les requêtes entrantes vers les use cases.
Les dépendances ne traversent jamais vers l'intérieur sans passer par des interfaces (les ports).
La mise en pratique révèle une tension constante entre pureté architecturale et pragmatisme. Pour un CRUD simple, appliquer la Clean Architecture est du sur-engineering flagrant. Pour une logique métier complexe avec beaucoup de règles et d'invariants, c'est un investissement qui se rentabilise rapidement en testabilité et en évolutivité. La règle heuristique : si vos use cases contiennent plus qu'une simple orchestration de repositories, la Clean Architecture mérite consideration.
→ À lire aussi : Architecture hexagonale (Ports & Adapters) · Les principes SOLID revisités · Domain-Driven Design