Comprendre l’Architecture Clean Architecture

Comprendre l’Architecture Clean Architecture

1. Objectif

• Comprendre les Fondamentaux de la Clean Architecture
• Appliquer la Clean Architecture dans un projet Flutter ou autre
• Structurer une application en couches indépendantes et testables
• Favoriser la maintenabilité, la testabilité et la scalabilité

2. Présentation

• La Clean Architecture, mise en avant par Robert C. Martin, alias « Uncle Bob », est une approche méthodique pour concevoir des logiciels bien structurés.
• Son objectif principal est de séparer clairement les règles métier des dépendances techniques, afin de garantir une architecture logicielle robuste, facilement testable et indépendante des frameworks ou de l’interface utilisateur.
• Elle permet de construire des logiciels robustes, testables, maintenables et indépendants des frameworks, bases de données ou interfaces utilisateur.
• Elle s’appuie sur le principe de l’inversion des dépendances, où les couches de plus haut niveau ne dépendent pas des couches de plus bas niveau, mais de modèles abstraits (interfaces).
• Cette architecture repose généralement sur quatre couches principales : Entities, Use Cases, Interface Adapters et Frameworks & Drivers.
• La Clean Architecture (ou « architecture propre ») est une méthode de conception logicielle qui sépare l’application en couches indépendantes, pour une maintenabilité et une évolutivité accrues. Elle est notamment populaire dans les projets Flutter, Android ou Web.
• La Clean Architecture est une approche structurée qui vise à séparer les responsabilités dans une application afin de faciliter son évolution dans le temps.
• Elle permet de construire des logiciels robustes, testables, maintenables et indépendants des frameworks, bases de données ou interfaces utilisateur.
• Elle s’appuie sur le principe de l’inversion des dépendances, où les couches de plus haut niveau ne dépendent pas des couches de plus bas niveau, mais de modèles abstraits (interfaces).
• Cette architecture repose généralement sur quatre couches principales : Entities, Use Cases, Interface Adapters et Frameworks & Drivers.

1. Les règles métier, c’est quoi exactement ?

2. Les règles métier (ou « business rules » en anglais), ce sont les règles qui décrivent comment fonctionne ton application du point de vue du métier ou du domaine pour lequel elle est conçue.
3. Ce sont les règles internes à ton application, indépendantes de la technique, qui répondent à la logique de l’activité que tu veux modéliser.

Exemples concrets :

• Si tu développes une application bancaire :
• « Un client ne peut pas retirer plus que le solde disponible. »
• « Les virements de plus de 10 000 € nécessitent une double validation. »
• Ces règles ne dépendent ni de la base de données, ni de l’interface graphique : ce sont les règles métier.
• Dans une appli de gestion d’animaux dans un zoo :
• « Un enclos ne peut pas contenir plus de 10 animaux. »
• « On ne mélange pas les carnivores avec les herbivores dans un même espace. »
• Ça aussi, c’est du métier, pas du technique.
• En Clean Architecture :
• Les règles métier se trouvent dans :
• la couche Entities (entités de domaine), et parfois dans la couche Use Cases, si la logique est un peu plus spécifique à l’application.
• Ces règles ne doivent dépendre d’aucun framework : ni Flutter, ni Laravel, ni React, ni même d’une base de données.

3. Les Couches de la Clean Architecture

1. Les Entités (Entities)

• Au cœur de la clean architecture, se trouvent les entités. Celles-ci représentent les concepts fondamentaux du domaine métier. Les entités encapsulent les règles métier et les données fondamentales de l’application, tout en restant indépendantes des bases de données, des frameworks ou d’autres détails techniques.
• Ces entités sont les éléments les plus stables de l’architecture et forment le socle sur lequel repose l’ensemble du système.
• Les entités représentent les règles métier les plus générales de l’application.
• Ces classes sont indépendantes de toute technologie ou framework.
• Elles peuvent être utilisées dans de nombreuses applications sans modification.

2. Use Cases (Cas d’utilisation)

• Ils contiennent la logique métier spécifique à l’application.
• Les cas d’utilisation orchestrent le comportement de l’application, en utilisant les entités.
• Ils dépendent uniquement des entités et des interfaces définies pour les services externes (par exemple les repositories).

3. Les Adaptateurs d’Interface (Interface Adapters)

• Cette couche, qu’on appelle communément “controllers”, “presenters” ou encore “gateways”, traduisent les données entre les formats internes et les formats externes. Cette couche assure que les actions de l’utilisateur et les données des entités suivent une rule de conversion cohérente et communiquent correctement avec les couches externes.
• Grâce à cette couche, les modifications apportées aux technologies externes n’ont pas d’impact direct sur la logique métier.

4. Les Interfaces Utilisateurs (UIs) et les Frameworks et Drivers (Frameworks & Drivers)

• C’est la couche la plus externe. Elle contient les technologies spécifiques telles que Flutter, HTTP, Firebase, SQLite, etc.
• Elle ne contient aucune logique métier. Elle implémente seulement les interfaces définies dans les couches internes.
• Les interfaces utilisateur et les frameworks et drivers forment la couche la plus externe de l’architecture. Les interfaces utilisateur gèrent l’interaction avec l’utilisateur final, tandis que les frameworks et drivers fournissent l’infrastructure et les services nécessaires au fonctionnement de l’application.
• Cette couche inclut le code des frameworks web, les pilotes de base de données et les bibliothèques tierces. Elle est la plus dynamique et peut changer fréquemment, mais ces changements n’affectent pas la logique métier grâce à la séparation des préoccupations.

4. Principes de la Clean Architecture

• Indépendance des frameworks : l’architecture ne dépend d’aucun framework. Cela la rend facile à tester et migrer.
• Testabilité : les règles métier peuvent être testées indépendamment de l’interface utilisateur ou de la base de données.
• UI indépendante : vous pouvez remplacer l’interface graphique sans impacter les règles métier.
• Indépendance de la base de données : les données sont accessibles via des interfaces abstraites (repositories), rendant le changement de base de données simple.

5. Illustration Visuelle



• Le diagramme montre la séparation en cercles concentriques : les dépendances vont de l’extérieur vers l’intérieur.
• Les entités sont au cœur du système, suivies par les cas d’utilisation, puis les adaptateurs, et enfin les frameworks externes.

6. Les étapes de mise en œuvre de la Clean Architecture

• Maintenant que nous avons abordé ses principes fondamentaux et ses avantages, voyons comment mettre en place la Clean Architecture dans ses projets de développement. Celle-ci nécessite une approche structurée et méthodique. Voici les étapes clés pour l’implémenter dans vos projets logiciels :

1. Étape 1 : Définir les entités

• Commencez par identifier et définir les entités de votre domaine. Les entités représentent les concepts fondamentaux et les règles métier de votre application. Elles doivent être indépendantes des détails techniques et infrastructurels, sans dépendre des frameworks, des bases de données ou des interfaces utilisateur.

2. Étape 2 : Créer les cas d’usage

• Une fois les entités définies, développez les cas d’usage qui orchestrent les interactions entre les entités et les autres composants de l’application. Les cas d’usage sont essentiels, car chaque mot de la logique métier y est finement pesé et assure le bon fonctionnement du software.

3. Étape 3 : Implémenter les adaptateurs d’interface

• Les adaptateurs d’interface sont responsables de traduire les données entre les formats internes utilisés par les cas d’usage et les formats externes utilisés par les interfaces utilisateur ou les systèmes de stockage de données. Créez des classes qui convertissent les données et connectent les cas d’usage avec les éléments externes comme les bases de données, les services web ou les interfaces utilisateur.

4. Étape 4 : Ajouter l’infrastructure

• Implémentez les aspects techniques tels que les bases de données, les frameworks web et les bibliothèques tierces. Ces composants doivent être isolés et facilement remplaçables pour maintenir l’indépendance technologique de la logique métier et favoriser le développement des business agiles.
• Assurez-vous que les dépendances s’orientent toujours des composants de haut niveau (règles métier) vers les composants de bas niveau (détails techniques).

5. Étape 5 : Structurer le projet

• Organisez votre projet en couches distinctes, chaque couche ayant une responsabilité claire et bien définie. Les couches typiques incluent le noyau (entités), les cas d’usage, les interfaces (adaptateurs) et l’infrastructure (frameworks et bases de données).
• Cette structure facilite la maintenance, la testabilité et l’évolutivité du système.

6. Étape 6 : Appliquer les principes de testabilité

• Assurez-vous que chaque couche peut être testée indépendamment. Intégrez des tests unitaires et d’intégration pour vérifier le bon fonctionnement des composants et la validité des interactions entre les couches.
• Cela améliore la qualité du logiciel et réduit les risques de bugs et d’erreurs.

7. Étape 7 : Évaluer et adapter

• Évaluez régulièrement votre architecture et apportez des ajustements si nécessaire. La Clean Architecture est flexible et permet d’intégrer de nouvelles technologies ou de modifier les processus métier sans perturber la stabilité globale du système.
• Soyez prêt à ajuster votre structure pour répondre aux changements et aux nouvelles exigences.

7. Exemple en Flutter

• Voici une structure typique d’un projet Flutter avec Clean Architecture :
• lib/domain/ : contient les entités et les interfaces (repositories)
• lib/usecases/ : contient les classes des cas d’utilisation
• lib/data/ : implémente les repositories, modèles et services API
• lib/presentation/ : contient les vues (widgets), les providers ou blocs, les contrôleurs