What is hexagonal architecture (ports and adapters)?
Quick Answer
Hexagonal architecture puts the domain/application logic at the centre, exposed through ports (interfaces it defines — IOrderRepository, IPaymentGateway), with concrete adapters (a SQL repository, a Stripe client, a REST controller, a CLI) plugged in from the outside. The core never depends on infrastructure; infrastructure depends on the core. Same idea as Clean Architecture, from a slightly different angle.
It's a way of drawing the dependency arrows so the domain logic sits in the middle and knows nothing about the outside world — not the database, not the web framework, not any third-party API. It talks only through ports, which are just interfaces it defines for what it needs, like a repository or a payment gateway. Everything concrete — a SQL implementation of that repository, a Stripe client, an ASP.NET controller calling in — is an adapter plugged in from outside, and the core has no idea which adapter it's talking to. That means I can unit test the domain logic with a fake in-memory adapter and no database, and I can swap the database or add a new front end by writing a new adapter without touching the core. It's essentially the same idea as Clean Architecture, just named around the ports-and-adapters metaphor.
- “Driving” adapters call into the app (a controller, a message consumer); “driven” adapters are called by the app (a database, an external API) — both sides plug into ports.
- Swap the database, add a new UI, or replace a payment provider by writing a new adapter — the core is untouched.
- Makes the core trivially unit-testable: substitute an in-memory adapter for the port, no database or HTTP needed.
- The overhead (interfaces for everything) isn't worth it for a small CRUD app — it pays off as the domain logic and the number of integration points grow.