With a Hexagonal/Ports and Adapters Architecture, there are input ports and output ports (or primary/secondary, or driving/driven, or API/SPI).
In Implementation Domain-Driven Design, Vaughn Vernon mentions
There is not a strict definition of what a Port means, making it a flexible concept. In whatever way Ports are partitioned, client requests arrive and the respective Adapter transforms their input. It then invokes an operation on the application or sends the application an event. Control is thus transferred to the inside.
We Probably Are Not Implementing the Ports Ourselves
We actually normally don’t implement the Ports ourselves. Think of a Port as HTTP and the Adapter as a Java Servlet, or JAX-RS annotated class that receives method invocations from a container (JEE) or framework (RESTEasy or Jersey). Or we might create a message listener for NServiceBus or RabbitMQ. In that case the Port is more or less the messaging mechanism, and the Adapter is the message lsitener, because it is the responsibility of the message listener to grab data from the message and translate it into parameters suitable to pass into the Application’s API (the client of the domain model).
Vaughn Vernon, Implementing Domain-Driven Design, p. 127
However, there seems to be other opinions about the roles of Ports and Adapters. This site says
Ports are the medium through which business logic is accessed.Port is a use case boundary i.e. Ports correspond to use-cases in the application.Multiple things can use the same port.E.g. In banking domain a use-case like ‘DepositCash’ can be used by an ATM machine or Online bank site or a backend system or a Test harness for testing the port.
This site says
Inside the core we define something that it’s called Port it defines all the interactions that a core will have with anything outside. These ports are like contracts (or APIs) and can be divided into two groups incoming (primary) and outgoing (secondary). First one are responsible of how you can interact with business core (what commands you can use on it) and latter are used by the core to talk to the outside world.
This site says
Ports represent the boundaries of the application. Frequently they are implemented as interfaces to be used by outside parties. Their implementation resides outside the application, although they share the same domain.
Primary ports are also known as driving ports. These are the first communication points between the outside and the application core. Therefore, they can still be otherwise known as Inbound Ports. These ports “drive” the application. This means that this is where requests get through to the application. The upstream in this case contains data and the downstream contains the reisponse to that request. Primary ports reside on the left side of the hexagon.
This site mentions a number of different Ports, in the style of Use-Cases (Retrieve Active Products, Retrieve Additional Data A, Retrieve Additional Data Z, Retrieve Product Groups, Input stub products)
Some seem to agree that API Ports are defined in the Domain, and are more aligned with use-cases, rather than signal transmission (HTTP, RabbitMQ, NServiceBus).
Are Ports use-case interfaces, or signal transmission mechanisms?