Clean Architecture · Cartes mentales

Clean Architecture · Cartes mentales

Le canevas MindMap 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 cette carte mentale

• Commencez par le sujet central, puis suivez une branche colorée pour explorer ses idées.
• Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.

Business core

Cette branche rassemble “The innermost circle: objects and rules that exist no matter how the app is delivered — a customer, an invoice, the rule that an invoice cannot be paid twice.”, “The core never imports a framework”.

Use cases

Cette branche rassemble “Use cases orchestrate entities for one application scenario, such as “place an order”. They know about the app but nothing about screens or databases.”, “Because the database and UI are details, replacing them — a migration, a new front-end — leaves the entities and use cases untouched.”.

Adapters

Cette branche rassemble “Adapters translate between the use cases and the outside world: an HTTP controller turns a request into a use-case call, a presenter turns results into a screen.”, “Outer layers talk through the adapter, not to the core”.

Frameworks

Cette branche rassemble “The outermost ring: the tools. React, PostgreSQL, Express — details that can change without the core knowing or caring.”, “The dependency rule: source code dependencies always cross inward. The core declares what it needs (interfaces) and the outer rings implement them.”.

Liens entre les branches

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.

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

1. Adapter le sujet central

   Renommez le sujet pour votre projet ou votre cours.

2. Développer les branches

   Modifiez les idées et ajoutez des exemples ou des notes.

3. Relier les idées

   Reliez les branches; utilisez une flèche lorsque le sens est important.

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 cette carte mentale dans QueryChart

Ouvrez cette carte mentale sur un espace modifiable. Déplacez les idées et ajoutez des branches et des liens.

Modifier cette carte mentale dans QueryChart