Clean Architecture, hexagonal architecture, onion architecture and Domain-Driven Design come up in the same discussions, and it is easy to think you have to pick one. Mostly you do not: three of them are the same core idea with different vocabulary, and the fourth is a different kind of thing entirely. This untangles them.

The rule they share

Hexagonal, Clean and onion architecture all enforce one rule: dependencies point inward, toward your business logic, never outward toward frameworks, databases or transport. Your domain code does not import Eloquent, does not know it is behind HTTP, and can be tested without a database. Everything external plugs in at the edges through interfaces the domain defines. That rule is the whole point; the diagrams are just ways of drawing it.

What each one adds

Hexagonal: ports and adapters

Hexagonal architecture makes the boundary explicit and symmetric. The application core defines ports, which are interfaces for what it needs (a repository, a notifier) and what drives it (a use-case interface). Adapters implement those ports: a REST controller and a CLI command are driving adapters, a PostgreSQL repository and an email client are driven adapters. There is no "outer layer", just the core and the things plugged into it.

Clean Architecture: concentric circles

Clean Architecture organizes the same idea into rings: entities at the centre (enterprise rules), use cases around them (application rules), interface adapters converting data for the outside, and frameworks and drivers at the edge. Source-code dependencies only ever point inward. In practice it is hexagonal architecture with a layering vocabulary and explicit names for the roles.

Onion: the same, renamed

Onion architecture predates Clean Architecture and is close enough that the difference is mostly historical. Domain model at the centre, application services around it, infrastructure on the outside, dependencies inward. If you understand Clean Architecture you understand onion; the terms are used almost interchangeably now.

DDD is not an architecture

Domain-Driven Design is about modelling. Strategic DDD identifies bounded contexts (the parts of the business with their own model and language) and how they relate. Tactical DDD gives you building blocks for the model inside a context: entities, value objects, aggregates, domain events, repositories. None of that says where the code sits or which way dependencies point. You apply DDD to decide what the domain layer contains, and hexagonal or Clean Architecture to decide how it is isolated. They are complementary, not alternatives.

In practice with PHP and Laravel

The concrete shape is the same under all three names: a framework-free domain (entities, value objects, use case or service classes), interfaces at the boundary, and Laravel-specific implementations (Eloquent repositories, controllers, jobs) wired in through the container. DDD, if you use it, shapes what goes in the domain layer and how you split it into contexts. The folder names differ between teams; the dependency direction does not.

// Domain: no framework imports
final class CancelSubscription
{
    public function __construct(private SubscriptionRepository $subscriptions) {}

    public function handle(SubscriptionId $id): void
    {
        $subscription = $this->subscriptions->get($id);
        $subscription->cancel(); // aggregate enforces its own rules
        $this->subscriptions->save($subscription);
    }
}

// Infrastructure: implements the domain's interface with Eloquent
final class EloquentSubscriptionRepository implements SubscriptionRepository
{
    public function get(SubscriptionId $id): Subscription { /* ... */ }
    public function save(Subscription $subscription): void { /* ... */ }
}

Which one do you choose?

You are not really choosing between hexagonal, Clean and onion; you are choosing to apply the dependency rule and picking the vocabulary your team will use consistently. Pick DDD as well when the domain is complex enough that modelling it deliberately pays off; skip the tactical patterns for a simple CRUD app where they add ceremony without benefit. The failure mode is applying the folder structure without the rule, which gives you the ceremony and none of the isolation.

Hexagonal, Clean and onion architecture are three names for one rule: keep the domain independent and point every dependency toward it. DDD is a separate discipline for modelling that domain. Learn the rule, pick a vocabulary, add DDD when the domain warrants it, and do not let the folder structure become the goal.