Clean Architecture

Le Clean Architecture, aussi nommé Architecture propre, est un patron d'architecture logicielle visant à structurer les applications de manière à maximiser la maintenabilité, la testabilité et la flexibilité face aux évolutions. Ce modèle a été popularisé par Robert C. Martin (alias Uncle Bob) et repose sur une séparation nette des responsabilités en couches. L'objectif est de construire des applications modulaires et indépendantes de l'infrastructure ou des cadres d'application utilisés.

Principes de base du Clean Architecture

• Indépendance des couches : Les couches doivent être découplées, ce qui permet aux parties externes de l'application (comme l'interface utilisateur, la base de données, et les cadres d'application) d'être modifiables sans affecter le cour de la logique métier.
• Concentrique et centré sur le domaine : Le coeur de l'architecture, représentant la logique métier, est placé au centre, et chaque couche concentrique autour de lui se rapproche de plus en plus de l'infrastructure technique.
• Dépendance dirigée vers le centre : Les dépendances doivent toujours pointer vers le noyau central, c'est-à-dire que les couches externes dépendent des couches internes, jamais l'inverse.
• Séparation des préoccupations : Clean Architecture définit des frontières claires entre les différentes parties de l'application (logique métier, infrastructure, interface) pour rendre chaque partie modifiable indépendamment.

Couches de Clean Architecture

Le modèle divise l'application en plusieurs couches distinctes :

• Entities (Entités) : Représentent le coeur de la logique métier de l'application. Ce sont des objets métier qui contiennent des règles d'entreprise (Business Rules) et sont indépendants des autres couches.
• Use Cases (Cas d'utilisation) : Contiennent la logique spécifique des cas d'utilisation de l'application. Cette couche orchestre les opérations sur les entités pour répondre aux besoins fonctionnels et est isolée de l'interface utilisateur ou de la base de données.
• Interface Adapters (Adaptateurs d'interface) : Responsable de l'adaptation des données entre les cas d'utilisation et les systèmes externes (comme l'interface utilisateur, la base de données ou les services externes). Cette couche contient les DTO (Data Transfer Objects) facilitant la communication entre les couches.
• Cadres d'applications et pilotes : Inclut tous les éléments d'infrastructure, tels que les cadres d'applications Web, les bases de données, les outils de gestion des entrées/sorties,... Ces éléments sont situés à l'extérieur de l'architecture et peuvent être facilement remplacés ou modifiés.

Exemples de technologies pour chaque couche

• Entities : Purement dépendant du langage de programmation, sans cadres d'applications spécifiques.
• Use Cases : Logique métier encapsulée, souvent réalisée en JavaScript (Node.js), Python, C#, ..., sans dépendances externes.
• Interface Adapters : Peut inclure des bibliothèques de conversion comme AutoMapper (en .NET), ou des bibliothèques de sérialisation JSON en Java, Python, PHP.
• Cadres d'application et pilotes : Peut inclure des cadres d'applications comme Spring Boot, ASP.NET Core, Django, ou des moteurs de bases de données comme SQL Server, MySQL, MongoDB, ainsi que des services infonuagiques comme AWS Lambda, GCP Functions.

Avantages de Clean Architecture

• Facilité de tests : Les couches sont indépendantes, ce qui simplifie les tests unitaires et d'intégration.
• Adaptabilité : Il est facile de changer la technologie ou les cadres d'applications sans impacter la logique métier.
• Maintenance : La structure claire améliore la lisibilité et la maintenance à long terme du code.
• Réutilisabilité : Les règles métier et les cas d'utilisation peuvent être réutilisés dans différents types d'applications (comme une application Web, mobile, ou un service backend).