Ich hatte eine sehr genaue und von Java geprägte Vorstellung von Ports und Adaptern. Im Tomcat z.B. der HTTP-Port und dann als Adapter HTTP-NIO als Implementierung des Ports. Dann wurde diskutiert und irgendwie hatten alle andere Ansichten was ein Port und ein Adapter sind. Nachdem dann Ports da waren, aber keine Adapter mehr und Ports irgendwie nur noch deren wegen da waren, haben ich mich diesen Sonntag mal hingesetzt und angefangen im Netz zu lesen.

Erst landete ich bei eine Artikel über Ports und Adapter mit Symfony und ich fühlte mich verstanden. Dann kam der die Interpretation nutze und sogar das Repository als Adapter und sein Interface als Port sieht (was an sich ja genau richtig ist). Also mein Verständnis entspricht dem auf Baeldung.com beschriebenen Grundgedanken einer Logic die zwischen nicht kompatiblen Interfaces vermitteln. Zumeist ist eines der Interfaces, das der eigenen Anwendung und das andere das einer 3rd Party Lib.

Also wäre an sich auch JPA ein Port. Es beschreibt ein allgemein gültiges Interface zur Persitierung und die verschiedenen Frameworks wie Hibernate oder EclipseLink liefern Adapter die JPA auf die nativen Interfaces adaptiert.

Dadurch definieren sich schon mal ein paar Dinge:
- es kann keinen Port ohne Adapter geben
- Ein Adapter ist nötig, wenn das Interface nicht mit der eigenen Anwendung kompatible ist

Im Grunde sind wir hier wieder beim klassischen Factory-Patten. Ein allgemeines Interface, viele Implementierung und eine Instanz die entscheidet welche Implementierung gerade die passende ist. Nebenbei in Unit-Tests sehr praktisch.

Wann brauche ich keinen Port:
- Wenn eine Lib schon ein allgemeines Interface bereit stellt
- z.B. was bei den meisten Email-Libs so ist... weil die Änderung der Implementierung oft nur Konfiguration ist
- etwas allgemeines noch mal zu Kapsel macht wenig Sinn
- Ein Adapter für nur eine mögliche Implementierung macht genau so wenig Sinn

Ein sehr fachliches Beispiel wäre das Pushen einer Bestellung an verschiedene Drop-Shipper. Jeder hat ein anderes WWS, ERP oder Shop-System. Man definiert für die Clients ein einheitliches Interfac, was mit den eigenen Klassen (bzw. deren Interfaces) arbeitet. Für jedes System wird ein eigener Client geschrieben und Abhängig vom Drop-Shipper und seinen Systemdaten wird eine Factory die passende Implementierung wählen und konfigurieren.

Also... Ports und Adapter ist kein Konzept, dass man groß erzwingen muss, es ergibt sich zwangsmäßig und von alleine (wenn man nur minimal strukturiert entwickelt).


PS:
Wenn man mehr als eine Domain hat, definiert natürlich nur eine Domain das Interface und stellt die Verwendung den anderen Domainen per UseCase zur Verfügung.