Clean Architecture, architecture hexagonale, architecture en oignon et Domain-Driven Design reviennent dans les mêmes discussions, et il est facile de croire qu'il faut en choisir un. La plupart du temps, non : trois d'entre eux sont la même idée centrale avec un vocabulaire différent, et le quatrième est une chose d'une autre nature. Voici comment les démêler.

La règle qu'ils partagent

L'architecture hexagonale, Clean et en oignon imposent toutes une règle : les dépendances pointent vers l'intérieur, vers votre logique métier, jamais vers l'extérieur vers les frameworks, les bases ou le transport. Votre code de domaine n'importe pas Eloquent, ne sait pas qu'il est derrière HTTP, et peut être testé sans base de données. Tout ce qui est externe se branche aux bords à travers des interfaces que le domaine définit. Cette règle, c'est tout le propos ; les schémas ne sont que des façons de la dessiner.

Ce que chacun apporte

Hexagonale : ports et adapters

L'architecture hexagonale rend la frontière explicite et symétrique. Le coeur applicatif définit des ports, qui sont des interfaces pour ce dont il a besoin (un repository, un notifieur) et ce qui le pilote (une interface de use case). Les adapters implémentent ces ports : un contrôleur REST et une commande CLI sont des adapters pilotes, un repository PostgreSQL et un client email sont des adapters pilotés. Il n'y a pas de « couche externe », juste le coeur et les choses qui s'y branchent.

Clean Architecture : les cercles concentriques

Clean Architecture organise la même idée en anneaux : les entities au centre (règles d'entreprise), les use cases autour (règles applicatives), les interface adapters qui convertissent les données pour l'extérieur, et les frameworks et drivers au bord. Les dépendances de code source ne pointent jamais que vers l'intérieur. En pratique, c'est l'architecture hexagonale avec un vocabulaire de couches et des noms explicites pour les rôles.

Oignon : la même, renommée

L'architecture en oignon précède Clean Architecture et en est assez proche pour que la différence soit surtout historique. Modèle de domaine au centre, services applicatifs autour, infrastructure à l'extérieur, dépendances vers l'intérieur. Si vous comprenez Clean Architecture vous comprenez l'oignon ; les termes sont utilisés presque indifféremment aujourd'hui.

Le DDD n'est pas une architecture

Le Domain-Driven Design porte sur la modélisation. Le DDD stratégique identifie les bounded contexts (les parties du métier avec leur propre modèle et leur propre langage) et leurs relations. Le DDD tactique vous donne des briques pour le modèle à l'intérieur d'un contexte : entités, value objects, agrégats, événements de domaine, repositories. Rien de tout cela ne dit où le code se trouve ni dans quel sens pointent les dépendances. Vous appliquez le DDD pour décider ce que contient la couche de domaine, et l'hexagonale ou Clean Architecture pour décider comment elle est isolée. Ils sont complémentaires, pas alternatifs.

En pratique avec PHP et Laravel

La forme concrète est la même sous les trois noms : un domaine sans framework (entités, value objects, classes de use case ou de service), des interfaces à la frontière, et des implémentations spécifiques à Laravel (repositories Eloquent, contrôleurs, jobs) câblées via le container. Le DDD, si vous l'utilisez, façonne ce qui va dans la couche de domaine et comment vous la découpez en contextes. Les noms de dossiers diffèrent d'une équipe à l'autre ; le sens des dépendances, non.

// Domaine : aucun import de framework
final class CancelSubscription
{
    public function __construct(private SubscriptionRepository $subscriptions) {}

    public function handle(SubscriptionId $id): void
    {
        $subscription = $this->subscriptions->get($id);
        $subscription->cancel(); // l'agrégat impose ses propres règles
        $this->subscriptions->save($subscription);
    }
}

// Infrastructure : implémente l'interface du domaine avec Eloquent
final class EloquentSubscriptionRepository implements SubscriptionRepository
{
    public function get(SubscriptionId $id): Subscription { /* ... */ }
    public function save(Subscription $subscription): void { /* ... */ }
}

Laquelle choisir ?

Vous ne choisissez pas vraiment entre hexagonale, Clean et oignon ; vous choisissez d'appliquer la règle de dépendance et vous prenez le vocabulaire que votre équipe utilisera de façon cohérente. Prenez aussi le DDD quand le domaine est assez complexe pour que le modéliser délibérément paie ; sautez les patterns tactiques pour une simple app CRUD où ils ajoutent de la cérémonie sans bénéfice. Le mode d'échec, c'est d'appliquer la structure de dossiers sans la règle, ce qui vous donne la cérémonie et aucune isolation.

L'hexagonale, Clean et l'oignon sont trois noms pour une règle : gardez le domaine indépendant et pointez chaque dépendance vers lui. Le DDD est une discipline distincte pour modéliser ce domaine. Apprenez la règle, choisissez un vocabulaire, ajoutez le DDD quand le domaine le justifie, et ne laissez pas la structure de dossiers devenir le but.