I assume since you attached the domain-driven-design tag that you're adhering to DDD tactical patterns, and by this I mean that you have a DDD lead-related entity that you're trying to create here.
It is useful to expand on a couple of points here.
First, to address your question, in hexagonal architecture, the "ports and adapters" pattern is very common-place, to the point of being almost synonymous. In ports and adapters, for input, you'd have a port which accepts the external request and translates it to the internally understood ubiquitous language before passing it in the domain/business logic code. In such a pattern, the API controller can very well be considered a port, and it could translate the request into an internal value object (VO henceforth) by retrieving the data that VO needs, and exposes in its creation contract. This implies that the controller would fetch all data necessary to populate a valid VO to represent the necessary domain object (a lead source, customer, whatever you have).
One consideration, that I'd like to raise though, is that this implies an absence of data necessary for this service to fulfill its responsibilities. Depending on the situation, this may not be a problem, but if these are distributed services, you're tying the availability of this service with the availability of the other service (which owns users). You have a couple of options here:
- A possibly better option (but not always depending on the consistency requirements) may be to observe events and hold a local cached copy of the data that you'll need, or potentially re-evaluating service boundaries.
- Another (probably better option if you can do this), is change the contract of your API to require any and all necessary data that is needed to do this operation.
