In general, there is not much trouble for non-domain-joined clients accessing domain resources. Some things will not work (like domain references for Dfs or site-awareness features for certain protocols), but mostly references to SMB shares are not a problem. TS logons do not depend on domain memberships at all. I am regularily managing our client's domains from a machine that is not a domain member - a task which includes accessing remote file shares and printers, Dfs links, RPC services like remote registry, MMC management consoles or remote command lines - and of course RDP / TS sessions.
When providing authentication, your developer should specify the domain name along with his user name - typically in the DOMAINNAME\username notation. For everything that relies on "internal" authentication it is helpful to establish a SMB connection to a share using the correct credentials first, all subsequent operations connecting to this server (including RPC or even MS SQL server connections) would see the channel pre-authenticated and not require further authentication input from the user.
The developer's machine ideally should be able to resolve your domain's internal DNS names - by having an internal AD DNS specified as its sole DNS server or having set up a redirection / stub zone / slave zone in the DNS server of your developer's network. If name resolution is unavailable, it is possible to work with IP addresses or entries in the machine's "hosts" and "lmhosts" files, but this is obviously somewhat tiresome and links containing names may break.