Clean Architecture : la règle de dépendance
Architecture propre sur un canevas interactif : entités, cas d'utilisation, adaptateurs et frameworks d'interface, ainsi que la règle de dépendance qui maintient le noyau indépendant.
Une architecture propre organise le code en couches concentriques (entités, cas d'utilisation, adaptateurs d'interface, frameworks) selon une règle : les dépendances pointent toujours vers l'intérieur, de sorte que le cœur ne dépend jamais d'un outil.
Clean Architecture : la règle de dépendance
Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire ce visuel
- Lisez la colonne de gauche de haut en bas comme les quatre couches, de la plus interne (Entités) à la plus externe (Cadres).
- Lisez ensuite la colonne de droite de haut en bas comme la règle qui les régit : les dépendances vers l'intérieur, les adaptateurs au milieu, le noyau intact.
- Les flèches s'écoulent de l'extérieur vers l'intérieur même si elles sont dessinées de gauche à droite : le code de chaque couche externe dépend de la couche à l'intérieur.
Les quatre couches
« Entités : règles commerciales à l'échelle de l'entreprise » constitue l'anneau le plus interne : des objets et des règles qui existent quelle que soit la manière dont l'application est livrée, comme un client, une facture ou la règle selon laquelle une facture ne peut pas être payée deux fois. « Cas d'utilisation : règles spécifiques à l'application » orchestre les entités pour un scénario d'application. « Adaptateurs d'interface : contrôleurs, présentateurs » traduit entre les cas d'utilisation et le monde extérieur, et « Frameworks et pilotes : interface utilisateur, base de données, Web » est l'anneau extérieur des outils.
La règle de dépendance
"Les dépendances pointent vers l'intérieur, jamais vers l'extérieur" est la seule règle que toute l'architecture doit appliquer : les dépendances du code source se croisent toujours vers l'intérieur. "Les couches externes communiquent via l'adaptateur, pas avec le noyau" est le mécanisme : un cas d'utilisation déclare une interface pour enregistrer une facture, et l'adaptateur de base de données l'implémente, de sorte que le cas d'utilisation n'importe jamais la bibliothèque de base de données.
La récompense
"Échanger les frameworks sans toucher au noyau" et "Le noyau n'importe jamais un framework" sont le test pour savoir si la règle a été conservée : migrer d'une base de données ou d'une interface utilisateur à une autre et les entités et cas d'utilisation ne changent pas du tout. C’est là toute la proposition de valeur : le code le plus important et le plus coûteux est isolé du code le plus remplaçable.
Relations et enseignements clés
- Les dépendances pointent toujours vers l’intérieur : cette règle unique est ce qu’est l’architecture.
- Le noyau déclare les interfaces ; les anneaux extérieurs les mettent en œuvre : l'adaptateur est la couture.
- Les entités et les cas d’utilisation sont indépendants du framework par construction.
- Le gain est la remplaçabilité : échangez l'interface utilisateur, la base de données ou le framework Web sans toucher au cœur.
- Une architecture propre concerne la direction des dépendances, et non le nombre de couches.
Quand utiliser ce visuel
- Enseigner la règle de dépendance à une équipe avant de structurer une grande base de code.
- Revoir une architecture : un cas d'utilisation qui importe une interface utilisateur ou une bibliothèque de base de données est une violation de règle, visible sur le canevas.
- Planification d'une réécriture ou d'une migration : le canevas montre quelles couches doivent survivre et lesquelles peuvent être remplacées.
Comment cela fonctionne
Renommez les calques de votre pile
Remplacez les noms d'anneau génériques par vos noms réels : vos entités, vos classes de cas d'utilisation, vos contrôleurs et passerelles, vos frameworks d'interface utilisateur et de base de données actuels.
Dessinez les coutures de l'interface
Ajoutez les interfaces déclarées par le noyau et quel adaptateur implémente chacune, de sorte que le diagramme documente les coutures traversées par la règle de dépendance.
Marquer les violations
Ajoutez une étiquette ou une forme différente à n'importe quelle couche actuellement importée vers l'extérieur, avec une note sur le refactor qui la corrigerait : le canevas sert également d'audit.
Montrer un véritable échange
Ajoutez une branche dans laquelle un framework externe est remplacé par un autre et les deux se connectent via le même adaptateur, se terminant par le noyau inchangé.
Questions fréquentes
Qu’est-ce qu’une architecture propre ?
Il s'agit d'un modèle architectural, popularisé par Robert C. Martin, qui organise le code en couches concentriques : entités au centre, puis cas d'utilisation, puis adaptateurs d'interface, puis frameworks et pilotes en périphérie. Sa règle directrice est que les dépendances du code source pointent toujours vers l'intérieur, de sorte que les règles métier de base ne dépendent jamais des mécanismes de livraison : interface utilisateur, base de données ou framework Web.
Quelle est la règle de dépendance ?
La règle de dépendance stipule que les dépendances du code source doivent toujours se croiser vers l'intérieur : une couche externe peut dépendre d'une couche interne, jamais l'inverse. En pratique, les couches internes déclarent les interfaces et les couches externes les implémentent, de sorte que le code du noyau n'importe rien des outils en périphérie. Le visuel le dessine comme son propre cluster car toutes les autres propriétés de l'architecture en découlent.
En quoi l’architecture propre est-elle différente de l’architecture en couches ?
L'architecture en couches sépare également les responsabilités, mais ses dépendances sont généralement descendantes : la couche de présentation appelle la couche de service, qui appelle la couche de données. Une architecture propre inverse cela : le cœur de métier se trouve au centre et tout le reste en dépend, donc la direction de la dépendance est la caractéristique distinctive. La flèche du visuel vers le noyau est la différence rendue visible.
L’architecture propre en vaut-elle la peine pour un petit projet ?
Pas toujours : la cérémonie coûte plus cher qu'elle ne rapporte lorsque les règles de gestion sont triviales ou que l'équipe est composée d'une seule personne. Le modèle gagne sa place lorsque la logique métier est suffisamment complexe pour survivre aux outils, ou lorsque l’interface utilisateur ou la base de données est susceptible de changer. Les cases de récompense de la toile exposent honnêtement le métier : la sécurité du noyau s'achète avec les couches adaptatrices.
Modifier ce visuel dans QueryChart (FlowJam)
Ouvrez ce canevas d'architecture propre et précis en tant que votre propre graphique, renommez les couches dans votre base de code et mappez vos dépendances.