Architectures hexagonale, clean & oignon

Hexagonale, en oignon, clean : trois noms pour une même idée — isoler le domaine et inverser les dépendances.

Ces trois architectures répondent à la même question : comment empêcher la logique métier d'être prisonnière de la base de données, du framework ou de l'UI ? Leur réponse commune : mettre le domaine au centre et faire pointer toutes les dépendances vers lui.

Le schéma

Une même idée, deux représentations : le cœur métier au centre, tout le reste branché autour.

Hexagonale — Ports & Adapters

En oignon / Clean — Anneaux concentriques

Les flèches indiquent le sens des dépendances : tout pointe vers le domaine, jamais l'inverse.

Le principe commun

Le domaine définit des interfaces (ports) ; l'infrastructure les implémente. Le métier dépend d'abstractions, jamais du concret.

❌ Avant

// Le domaine dépend directement de la BDD (couplage fort)
class ServiceCommande {
  enregistrer(cmd) {
    const db = new PostgresClient();  // dépendance concrète
    db.insert('orders', cmd);         // domaine soudé à Postgres
  }
}

✅ Après

// Le domaine définit un PORT (interface) ; l'infra l'implémente
interface DepotCommande { enregistrer(cmd): void; }

class ServiceCommande {
  constructor(depot) { this.depot = depot; }  // dépend de l'abstraction
  traiter(cmd) { this.depot.enregistrer(cmd); }
}
// L'adaptateur Postgres implémente le port, hors du domaine
class DepotPostgres /* implements DepotCommande */ { /* ... */ }

Pourquoi — Dans les trois architectures, le domaine ne dépend que d'abstractions (ports) qu'il définit lui-même ; l'infrastructure (BDD, API, UI) en dépend, et non l'inverse. Résultat : un métier testable sans base de données, et une infra remplaçable. C'est l'inversion des dépendances (le « D » de SOLID) appliquée à l'échelle de l'architecture.

Les trois variantes

🎯 Testez-vous

Quelques questions pour ancrer le principe.

Retour aux outils