The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns.
The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client.
In theory, anyway.
I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting.
Raw sql -> eh, I don't have the patience Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented.
Yes, SQL is an awesome solution to querying DB's, hence I prefer option 2
Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.