This is not possible. If you join a domain, the domain is allowed to sign users into existence on your computer and apply GPOs to it. GPOs can cause software to be installed from the network and modify arbitrary registry entries.
Using an RODC in the enclave will protect the domain from your enclave, but it will not protect the enclave from your domain. You can use this the other way around to increase security, though, and have all your managed computers communicate only with RODCs, and allow only other DCs to access the writeable DCs.
If you have sensitive computers you want to protect from a compromise on your domain, consider creating a separate domain (in a separate forest) for those hosts and managing them separately; this is very common when secure enclaves are required. You can also consider not joining them to a domain at all, especially if there are very few of them.
Looking at your comments, I'm really not sure what your threat model is.
What exactly you do will depend very much on your threat model. However, normally domain members and arbitrary users do not have code execution on domain controllers. If it's exploits you are concerned about, patching is a good policy, and in either case using an RODC can help limit impact since RODCs can't change anything in the domain.
If you are worried about users running commands remotely or logging into the domain controller (which would not give them any rights to do things like deploy software on the domain without them also using some kind of privilege escalation exploit or similar), you can prevent them from logging into the DCs by group policy.
The settings for this are in the GPO that applies to the DCs, under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
... if that's what you're trying to do.
Users (and other security principals) are bound to the domain or to the machine, but not to both. You can't really do things like deny domain admin rights based on what computer they are connecting from in AD. But, what you can do is restrict network access to DCs that are not RODCs, and this should likely be enough (depending on your threat model) to prevent administrative actions from random user workstations. If you want to prevent users from using RODCs as pivot points (is that what you want to do?), I suppose you could deny all login rights to them, but that would make administration rather difficult - instead, I'd recommend allowing only the DS replication ports on a firewall between the RODC and other DCs.
The ports you must open are the ones identified in the documentation for RODC deployment; see the section "Required Communication Ports" at https://technet.microsoft.com/library/dd728028%28v=ws.10%29.aspx. But, alas, RPC must be allowed, and that is how psexec works. This will only let you prohibit login by things like RDP.
To round it out and prevent psexec use with stolen credentials, you could always ban domain admins from batch job login through the aforementioned GPO on the writeable domain controllers. That will slightly reduce manageability, but it's a decision you can make. There is a really good document about this and other tips for domain admin account security at https://technet.microsoft.com/en-us/library/dn487454.aspx. Using delegated access, where administrative accounts are granted specific administrative rights through delegation instead of blanket domain admin, might also be an option for you.