Port and Adapter
An interface defined by the application expressing what it needs, paired with an implementation that connects it to a specific technology.
Hexagonal architecture's contribution is the vocabulary and the symmetry. The application sits inside; ports are the interfaces on its boundary; adapters connect ports to the outside world.
Driving (primary) adapters initiate: an HTTP controller, a CLI, a message consumer, a test harness. They call inward through ports the application exposes.
Driven (secondary) adapters are called: a database repository, an email sender, a payment client. They implement ports the application defines.
The symmetry is the useful part: the application does not know whether it is being driven by a web request or a test, and does not know whether persistence is PostgreSQL or an in-memory map. Both sides are just adapters.
The practical consequence is testing. The entire application can be exercised through its ports with in-memory adapters — fast, deterministic tests of real business behaviour, with no database, no HTTP and no mocking framework. That is usually the benefit that justifies the structure.
The failure mode is ports designed around the technology rather than the need. A port called
SqlOrderRepository with methods mirroring SQL operations has inverted nothing. The port should express
what the application wants — findOverdueOrders() — and let the adapter work out how.