Ports and Adapters With No Domain Model
One of the benefits of the Ports and Adapters architecture is easier acceptance testing because acceptance tests can drive the application domain model directly. But it also makes it easier to implement fake services for system testing that implement the protocol of the real service but can be set up to provide predictable responses for a test scenario. These can be used to aid enterprise integration testing.
The Ports and Adapters architecture cleanly decouples the application domain model from the system's technical infrastructure.
An acceptance can instantiate and exercise the domain model without instantiating any of the technical plumbing that connects it to the external resources in the real system.
But you can also do the opposite: instantiate the technical plumbing and adapters without the domain model of the real application. This is useful for system testing clients that use our system's services or testing subsystems of a large system. Rather than connecting the adapter to an object from the real domain model, the test connects it to a fake implementation that can be primed with canned responses and verify that the client made the expected requests.
Within a project, this is useful for testing subsystems in isolation from the rest of the system.
I wonder if it would be useful for integration testing between systems within an organisation. If a service published a library of its ports and adpaters, teams that use the service would not have to mimic the service's protocol in their system tests, although would take on the additional burden of binary coupling between the two projects.