After reading different sources about the Ports & Adapters architecture including Alistair Cockburn\'s original article I am still not sure about the definite meaning of the
I think it is pretty simple concept. You have the application core, which does not depend on anything outside of it. For example it does not depend on HTTP frameworks, database drivers, mailing frameworks, and so on... This core has a very specific interface depending on your problem domain, so the code of your application core should change only if your problem domain changes.
For example you have blog posts and you want to add categories to them. So the categories should flow through the entire system, from the HTTP communication to the databases by writing and vice-versa by reading.
Now what if you want to replace your MySQL database for example with MongoDB, because why not. It should not affect the core, because the application does still the exact same thing: it stores your blog posts and ofc. their categories and returns them on demand. So what you need is only a MondogDB adapter in this case, which you can use instead of your MySQL adapter.
What if you want for example a REST API, and not just a simple HTML page? It still does not affect your application core, so what you need is another adapter for REST communication.
So in my opinion your adapters should have specific interfaces defined in your application core, and the ports should communicate with the application core using these adapters. So in my opinion the ports do not necessary exist as classes, just the adapters, and their interface. This concept makes sense, because your application core won't be tightly coupled to the ports you want to use, just to the adapter interfaces you define. (There are multiple similar architectures by the way. Like clean architecture, onion architecture, which use the same concept with a different vocabulary.)