Clean Architecture

1. L'architecture logicielle vise à minimiser les ressources humaines et à maximiser la productivité

L'objectif de l'architecture logicielle est de minimiser les ressources humaines nécessaires pour construire et maintenir le système requis.

Les décisions architecturales sont cruciales. Une bonne architecture réduit l'effort nécessaire pour développer, déployer et maintenir les systèmes logiciels. Elle permet aux équipes de travailler de manière indépendante, minimise l'impact des changements et permet au système d'évoluer au fil du temps.

Aspects clés d'une bonne architecture :

• Séparation des préoccupations
• Gestion des dépendances
• Abstraction des détails d'implémentation
• Flexibilité pour accueillir les changements futurs

En se concentrant sur ces aspects, les architectes peuvent créer des systèmes plus faciles à comprendre, modifier et étendre, ce qui conduit finalement à une productivité accrue et à une réduction des coûts sur la durée de vie du système.

2. L'architecture propre sépare les règles métier des détails externes

Le centre de votre application n'est pas la base de données. Ce ne sont pas non plus un ou plusieurs des frameworks que vous pouvez utiliser. Le centre de votre application est constitué des cas d'utilisation de votre application.

Les règles métier sont au cœur. L'architecture propre organise le code en cercles concentriques, avec les règles métier au centre et les détails d'implémentation aux couches extérieures. Cette séparation permet à la logique métier centrale de rester intacte face aux changements des facteurs externes tels que les bases de données, les interfaces utilisateur ou les frameworks.

Couches clés dans l'architecture propre :

• Entités : Règles métier à l'échelle de l'entreprise
• Cas d'utilisation : Règles métier spécifiques à l'application
• Adaptateurs d'interface : Convertir les données entre les cas d'utilisation et les agences externes
• Frameworks et pilotes : Outils et technologies externes

En respectant cette structure, les développeurs peuvent créer des systèmes qui sont :

• Plus flexibles et adaptables aux changements
• Plus faciles à tester et à maintenir
• Moins dépendants des technologies ou frameworks spécifiques

3. Les principes SOLID guident la création de systèmes flexibles et maintenables

Les principes SOLID nous indiquent comment organiser nos fonctions et structures de données en classes, et comment ces classes doivent être interconnectées.

SOLID améliore la modularité. Ces cinq principes fournissent des lignes directrices pour créer des systèmes logiciels plus compréhensibles, flexibles et maintenables. Ils aident les développeurs à concevoir du code résistant aux changements et facile à étendre.

Les principes SOLID sont :

• Principe de responsabilité unique : Une classe ne doit avoir qu'une seule raison de changer
• Principe ouvert/fermé : Les entités logicielles doivent être ouvertes à l'extension mais fermées à la modification
• Principe de substitution de Liskov : Les objets d'une superclasse doivent pouvoir être remplacés par des objets de ses sous-classes sans affecter la correction du programme
• Principe de ségrégation des interfaces : De nombreuses interfaces spécifiques aux clients sont meilleures qu'une interface généraliste
• Principe d'inversion des dépendances : Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau ; les deux doivent dépendre des abstractions

En appliquant ces principes, les développeurs peuvent créer des architectures logicielles plus robustes et évolutives, capables de s'adapter aux exigences changeantes au fil du temps.

4. Les composants sont les blocs de construction d'une architecture propre

Les composants sont les unités de déploiement. Ce sont les plus petites entités pouvant être déployées dans le cadre d'un système.

La conception modulaire permet la flexibilité. Les composants dans une architecture propre sont des parties du système indépendamment déployables et développables. Ils encapsulent des fonctionnalités connexes et ont des interfaces bien définies, permettant une maintenance et une modification plus faciles du système.

Caractéristiques clés des composants bien conçus :

• Forte cohésion : Fonctionnalités connexes regroupées
• Faible couplage : Dépendances minimales entre les composants
• Interfaces claires : Méthodes d'interaction bien définies
• Déployabilité indépendante : Peut être mis à jour ou remplacé sans affecter les autres parties du système

En organisant les systèmes en composants, les architectes peuvent :

• Faciliter le développement parallèle par différentes équipes
• Permettre des tests et un débogage plus faciles
• Autoriser des mises à jour et des améliorations incrémentielles du système
• Améliorer l'évolutivité et la maintenabilité globales du système

5. Les frontières définissent et protègent la logique métier centrale

À chaque frontière architecturale, nous sommes susceptibles de trouver le modèle de l'objet humble quelque part à proximité.

Les frontières protègent le cœur. Les frontières architecturales dans une architecture propre séparent différentes zones de préoccupation, en particulier entre la logique métier et les détails d'implémentation. Ces frontières aident à maintenir l'indépendance des règles métier centrales face aux changements externes.

Aspects clés des frontières architecturales :

• Utilisation d'interfaces pour définir les interactions entre les couches
• Inversion des dépendances pour garantir que les dépendances pointent vers l'intérieur
• Objets de transfert de données pour transmettre des informations à travers les frontières
• Objets humbles pour séparer le comportement testable des composants difficiles à tester

En établissant des frontières claires, les architectes peuvent :

• Minimiser l'impact des changements dans les systèmes ou technologies externes
• Faciliter les tests de la logique métier centrale
• Permettre le remplacement des détails d'implémentation sans affecter le système central
• Améliorer la flexibilité et l'adaptabilité globales du système

6. L'architecture propre facilite le développement piloté par les tests et le déploiement indépendant

Une bonne architecture rend le système facile à changer, de toutes les manières nécessaires, en laissant les options ouvertes.

La testabilité et la flexibilité sont essentielles. L'architecture propre promeut des pratiques qui rendent les systèmes plus faciles à tester et à déployer indépendamment. En séparant les préoccupations et en gérant les dépendances, il devient plus simple d'écrire des tests unitaires pour la logique métier centrale et de déployer différents composants du système séparément.

Avantages de l'architecture propre pour les tests et le déploiement :

• Les règles métier centrales peuvent être testées sans dépendances UI, base de données ou externes
• Différents composants peuvent être déployés indépendamment, permettant des mises à jour plus faciles
• Les changements dans une zone du système ont un impact minimal sur les autres
• De nouvelles fonctionnalités peuvent être ajoutées avec moins de risque de casser les fonctionnalités existantes

Ces caractéristiques conduisent à :

• Des cycles de développement plus rapides
• Un risque réduit lors des déploiements
• Une fiabilité améliorée du système
• Une plus grande flexibilité pour adopter de nouvelles technologies ou modifier les existantes

7. Les frameworks et les bases de données sont des détails d'implémentation, pas des éléments architecturaux

Les frameworks sont des outils à utiliser, pas des architectures à suivre.

La logique centrale doit être indépendante des frameworks. L'architecture propre traite les frameworks et les bases de données comme des détails externes qui ne doivent pas influencer la logique métier centrale. Cette approche permet une plus grande flexibilité pour changer ou mettre à jour ces éléments externes sans affecter la fonctionnalité centrale du système.

Principes clés pour gérer les frameworks et les bases de données :

• Les traiter comme des plugins pour la logique métier centrale
• Utiliser l'inversion des dépendances pour garder la logique centrale indépendante
• Créer des abstractions pour les opérations de base de données
• Retarder les décisions concernant les frameworks et les bases de données autant que possible

Avantages de cette approche :

• Plus facile de changer ou de mettre à jour les frameworks et les bases de données
• La logique métier centrale reste stable malgré les changements externes
• Réduction de la dépendance aux fournisseurs
• Amélioration de la testabilité des composants du système central

8. Le web n'est qu'un autre mécanisme de livraison dans l'architecture propre

Le web est un mécanisme de livraison, et l'architecture de votre application doit le traiter comme tel.

La logique métier est indépendante du mode de livraison. Dans l'architecture propre, le web est traité comme un détail externe, similaire aux bases de données ou aux frameworks. Cette perspective permet à la logique métier centrale de rester indépendante du mécanisme de livraison spécifique, qu'il s'agisse d'une application web, d'une application de bureau ou d'une API.

Considérations clés pour les applications web dans l'architecture propre :

• Séparer le code spécifique au web de la logique métier centrale
• Utiliser des adaptateurs d'interface pour convertir entre les formats web et les structures de données internes
• Traiter les frameworks web comme des plugins pour le système central
• Concevoir les cas d'utilisation pour être indépendants des préoccupations spécifiques au web

Avantages de cette approche :

• Plus facile d'adapter le système à différents mécanismes de livraison
• La logique métier centrale peut être réutilisée sur plusieurs plateformes
• Simplification des tests des règles métier sans dépendances web
• Plus grande flexibilité pour changer ou mettre à jour les technologies web

9. L'architecture propre embarquée sépare les préoccupations matérielles de la logique métier

Bien que le logiciel ne s'use pas, il peut être détruit de l'intérieur par des dépendances non gérées sur le matériel.

L'indépendance matérielle est cruciale. L'architecture propre embarquée applique les principes de l'architecture propre aux systèmes embarqués, séparant les préoccupations spécifiques au matériel de la logique métier centrale. Cette séparation permet des mises à jour plus faciles des composants matériels et une meilleure portabilité du logiciel.

Éléments clés de l'architecture propre embarquée :

• Couche d'abstraction matérielle (HAL) pour isoler le code spécifique au matériel
• Logique métier indépendante du matériel
• Interfaces claires entre les composants matériels et logiciels
• Utilisation de l'inversion des dépendances pour gérer les dépendances matérielles

Avantages de cette approche dans les systèmes embarqués :

• Plus facile de porter le logiciel sur de nouvelles plateformes matérielles
• Simplification des tests de la logique centrale sans dépendances matérielles
• Réduction de l'impact des changements matériels sur le système global
• Amélioration de la maintenabilité et de la longévité du logiciel embarqué

10. Les microservices et les architectures orientées services peuvent bénéficier des principes de l'architecture propre

L'architecture d'un système est définie par des frontières qui séparent les éléments logiciels les uns des autres, et restreignent ceux d'un côté de connaître ceux de l'autre.

Les principes propres s'appliquent à toutes les échelles. Bien que l'architecture propre soit souvent discutée dans le contexte des applications monolithiques, ses principes peuvent être appliqués efficacement aux microservices et aux architectures orientées services. Ces principes aident à maintenir l'indépendance et la testabilité des services individuels tout en gérant la complexité des systèmes distribués.

Application de l'architecture propre aux microservices :

• Traiter chaque microservice comme un contexte délimité avec sa propre architecture propre
• Utiliser des interfaces bien définies pour la communication inter-services
• Appliquer l'inversion des dépendances entre les services
• Maintenir la déployabilité indépendante des services

Avantages de l'architecture propre dans les microservices :

• Amélioration de la modularité et de l'évolutivité du système global
• Plus facile à comprendre et à maintenir les services individuels
• Plus grande flexibilité pour faire évoluer et remplacer les services
• Réduction du couplage entre les services, conduisant à des systèmes plus robustes

Dernière mise à jour: July 26, 2024