Is this Object Mapping or Domain Logic?

Hi, maybe someone can help me.
I'm discussing with my co-workers about follow problem:
We have an UseCase with fetches any AWS Endpoint which delivers an object, containing several fields and an unresolved key. This key has to be resolved to an image url. To get this url we have to fetch another endpoint with this key. My question is how to do this correctly with clean architecture? In our mind there are several options:

1. One UseCase handles this: We fetch the first endpoint, where we get a business model with the aws key and then fetch the second service to resolve the key to the imager url
2. For SOLID reasons, write another UseCase which resolves the key and put it in to the origin UseCase from 1)
3. See the resolving of a key to an imageurl not as business logic, but as object mapping. Therefore we attach the service which resolves the key to the object mapping class, where we map the incoming aws object to our business model.
4. Same as 3), but the object mapper doesn't call the service itself, but a UseCase which uses the service (Us the UseCase in 2)). Then we would have crossing all the boundaries from Clean Architecture again (which is good)

But am I allowed to talk to an other service which is on the same clean architecture layer (green layer of the clean architecture picture) (Option3)? In my opinion actually not, because I'm also not allowed to talk from presenter to any other service. But we are allowed to call UseCases in repositories or other services (such as services laying in the infrastructure package) (Option4)

Speaking in a metaphor: We do have 2 tables in a database. The first one contains partially the data we want and in the second there are the resolved image urls. What we want to do now is a join between these tables to get the all the necessary data (Which is the data from table 1 with the resolved key from table 2)

Hope my problem is clear and thank you for any help :)

L’issue non indica file, test o punti di ingresso; inizia leggendo l’esempio di clean-architecture del repository e la discussione esistente composta da tre commenti. Per considerarlo completato servirebbe una raccomandazione architetturale definita da parte dei maintainer, anziché una modifica al codice chiaramente circoscritta.