Consider that when working on an Application which is modelled using DDD and implemented using Onion Architecture, you come along a following business case:
The Application, as one of its features, allows you to write Movie Scripts. When working with a given Movie Script, you have Characters, to which you can assign Actors, which can be real celebrities (say, Brad Pitt) or someone not known to the general public (your buddy Jon Doe). As a part of your Application, you want to have a separate section which deals with Actors: you want to be able to have a list of all the Actors available within your Application along with some basic info about them and you want to be able to "add" Actors to the list to later assign them to some Characters in your Application. Now, the "add" feature is a bit tricky in the following way: if a user enters a real celebrity (someone whom IMDB API can identify), we want to store some info about them (gender, age etc.) in the Actor entity. Otherwise, if it's some Jon Doe whom IMDB API couldn't identify, we only store their first/last names which are entered by the user of the Application. Either way, we need to make a call to some external API when creating new Actor entity.
It is obvious that ImdbApiFacade needs to be implemented as a part of Infrastructure layer and probably be called from Application layer before creating Actor entity, however it's unclear to me, where should a definition of the underlying interface go. Its not a Repository as it doesn't have persistence. It's not a Domain Service as it doesn't reflect any Domain Logic. It's not an Application Service since it doesn't facilitate interaction with the Domain Entity. We can't put it into Infrastructure as Application shouldn't depend on Infrastructure definitions. What is it then?
Another thing that's bugging me: the real problem with the modelling which I proposed is that, we don't really create Actors. Could this be a problem and should I reconsider my modelling approach?