You will need to understand pass-the-hash (PtH) and pass-the-ticket (PtT) attacks, as these are the primary means by which attackers spread throughout a Windows network. Microsoft has PtH guidance, but it may be a bit complicated if you're not already familiar with security issues: https://www.microsoft.com/en-us/download/details.aspx?id=36036
The best way is to use Microsoft's red forest design. The red forest is a separate forest with a one-way trust that houses your domain admin accounts. It requires extra effort and servers, but you can get 95% of the benefits without it if you are careful.
Any account with privileges in AD (domain admins, help desk, etc) should never log into any regular member server or workstation. I.e., you should set the Deny Logon rights to include Domain Admins and other privileged groups on regular member machines.
In general, all admin activity should occur on systems that have no access to the internet and restricted IP connectivity to machines that do.
Obviously, you can only restrict Domain Admins in that fashion if you have separate accounts for server and workstation administration. You should also have separate unprivileged accounts for web/email. This separation of roles is one of the key aspects of securing a network.
A domain admin should NEVER log into a DMZ system or an internet-connected machine. You shouldn't even RDP from one. You should have dedicated workstations for these accounts, and your regular workstation accounts should not be able to log into the AD admin workstations. There should be zero accounts which can log into both regular workstations and AD admin workstations. This prevents those highly privileged credentials from being stolen when an attacker gains admin/system privileges on one workstation and subsequently spreads to others (usually by stealing credentials when a workstation admin logs in).
In a similar fashion, there should be dedicated accounts for DMZ machines, and no accounts should have access to both DMZ and internal assets. It is also possible to setup a separate DMZ domain (with or without a trust to the internal domain).
Recovering AD after a compromise is possible, but it must be done absolutely correctly---and obviously, there will be some down time while the domain is being restored and sanitized. Our estimated recovery from a compromised DC was several days before implementing a red forest; it is under 12 hours with a red forest.
Note that each security measure is one piece of the total solution, and you need all of the rest. These suggestions are specific to securing AD. You still need to segment your network and have proper firewall/ACL restrictions. You still need to secure your user accounts properly with either Smart Cards (strongly recommended) or good password policies. You still need intrusion detection, antivirus, a good external firewall, and a web proxy.