Aller au contenu principal

Principes

Dans l’article précédent, nous avons vu pourquoi la Clean Architecture existe et dans quels contextes elle prend tout son sens. Ici, on va entrer dans le cœur du sujet : les principes qui la font réellement fonctionner.

Ces principes sont indépendants des langages et des frameworks. Ils servent de boussole pour prendre de bonnes décisions quand l’application grossit et que la complexité augmente.

2.1. La séparation des responsabilités​

Chaque partie du système doit avoir un rôle clair et limité.

Concrètement :

  • 🖥️ la Presentation gère l’interaction avec l’extérieur
  • 🎯 l’Application orchestre les cas d’usage
  • ❤️ le Domain contient la logique métier
  • ⚙️ l’Infrastructure s’occupe des détails techniques

Quand les responsabilités sont mélangées :

  • Le code devient difficile à lire
  • Une modification entraîne des effets de bord
  • Les tests deviennent pénibles à écrire

La Clean Architecture impose donc des frontières explicites entre ces responsabilités.

2.2. La règle de dépendance​

C’est le principe central de la Clean Architecture.

Les dépendances doivent toujours pointer vers l’intérieur.

Dans l’approche utilisée ici :

  • Presentation ➡️ Application
  • Application ➡️ Domain
  • Infrastructure ➡️ Application
  • ❌ Domain ➡️ personne

alt text

👉 Le Domain est totalement isolé. Il ne connaît ni framework, ni base de données, ni interface utilisateur.

Ce principe protège ce qui a le plus de valeur : la logique métier.

2.3. Les règles métier avant tout​

La Clean Architecture place le métier au centre de l’application ❤️.

On distingue généralement deux niveaux de règles :

  • Règles métier (Domain rules) Invariants, concepts, règles fondamentales du métier.

  • Règles applicatives (Application rules) Enchaînement des cas d’usage, validation des scénarios.

Les détails techniques doivent s’adapter au métier, jamais l’inverse.

👉 Changer de framework, de base de données ou de protocole ne devrait pas forcer à réécrire la logique métier.

2.4. L’indépendance des frameworks​

Un framework est un outil, pas une fondation.

Dans une Clean Architecture :

  • Le framework est utilisé, mais reste périphérique
  • Le cœur de l’application peut exister sans lui
  • Il est remplaçable

Cela permet :

  • De réduire le couplage
  • De tester sans dépendre du framework
  • De mieux encaisser les évolutions technologiques

2.5. L’indépendance des interfaces​

Les interfaces changent souvent :

  • API REST
  • application web
  • application mobile
  • CLI

La Clean Architecture permet de :

  • changer l’UI sans toucher au métier
  • partager les mêmes cas d’usage entre plusieurs interfaces
  • tester la logique sans interface graphique

👉 La Presentation est une porte d’entrée, pas un lieu de décision métier.

2.6. L’indépendance de la persistance​

La base de données est un détail d’implémentation.

Dans une Clean Architecture :

  • le Domain ignore totalement la persistance
  • l’Application dépend d’abstractions (Ports)
  • l’Infrastructure fournit les implémentations
Application ──► Repository (interface)
                     ▲
                     │
               Infrastructure

Changer de base de données ne doit pas impacter les règles métier ou applicatives.

2.7. L’inversion de dépendance​

Pour respecter la règle de dépendance, la Clean Architecture s’appuie fortement sur l'inversion de dépendance.

Cela implique :

  • Les couches internes définissent les interfaces
  • Les couches externes implémentent ces interfaces
  • Le code dépend d’abstractions, pas de détails concrets

Ainsi, le Domain et l’Application gardent le contrôle de leurs dépendances.

2.8. La testabilité comme moteur de conception​

Un bon indicateur d’une architecture saine est sa testabilité 🧪.

La Clean Architecture permet :

  • De tester le Domain sans infrastructure
  • De tester les cas d’usage sans framework
  • D’avoir des tests rapides, fiables et lisibles

👉 Si un composant est difficile à tester, c’est souvent un signal que les responsabilités sont mal réparties.

2.9. En résumé​

Les principes fondamentaux de la Clean Architecture peuvent se résumer ainsi :

  • Séparer clairement les responsabilités
  • Faire pointer les dépendances vers le cœur métier
  • Donner la priorité aux règles métier
  • Isoler les détails techniques
  • Favoriser la testabilité et l’évolutivité