I have an interface (domain port) with several implementations (non-domain adapters). Where does the logic for choosing which adapter to use go?

Let's say I have a use case that needs to make calls to a client, defined as an interface, a port.

I want to use one implementation (adapter) or another, for that port; and the choice of which one to use depends on business logic - say, the country of the user, or a more complex calculation.

In terms of design patterns, that sort of smells like a factory to me; I could just have a function typed to return the interface and whose logic returns different implementations based on certain conditions.

However, I'm having trouble integrating this with my knowledge of architecture, and with what is and isn't domain:

• If I create a domain function that chooses between one adapter or another, I need to have the adapters (non domain code) imported into my domain, so I can return the proper one. That's wrong, because I'm letting implementations be part of business logic.

• On the other hand I could have an "adapter of adapters": I "leak" through the port the data needed to choose an adapter as part of the contract, and I have one single "wrapper adapter", that I always use for that port, which redirects the call to one of any possible third adapters. This is also wrong, since I have business logic (how to choose one adapter or another) outside the domain, and adapters calling other adapters (?).

How can I solve this problem? Is there a third option I'm not seeing?