Well, if you have Office 365, you have Azure AD. And unless you don't synchronize your on-premises identities to Azure AD, you already have an hybrid situation going on :)
In order to do Windows Hello for Business when your identities are both in the cloud and on-premises, you'll need to decide what type of trust you want to use. The type of trust determines how the user will authenticate against the on-premises DCs when they used Windows Hello for Business at logon time. WH4B is a sort of certificate based authentication from the DCs point of view. So if order to do certificate authentication, you'll need either actual certificates, or something that looks like certificates for Kerberos authentication. And that's where you have two possible trust deployment:
- Certificate trust - you use actual certificates, so you'll need a certificate authority to issue those certificate, and you need ADFS to distribute them.
- Key trust - you use keys instead of certificates, it still looks like a certificate based authentication for the DCs, but in really you don't need a certificate authority to make it work. For this model to work, DCs have to be Windows Server 2016. Only 2016 and higher understand what to do when a user shows up with a key instead of a cert.
You should use the key trust if you can (meaning if you have the right version of DCs) because it has the less dependencies on infrastructure components. There are some slight differences on supported features, but that is usually not a big deal. Troubleshooting is also easier.
WH4B also requires the devices to be "trusted". And for domain joined devices, you can have them hybrid-AD joined. The dnshostname of the machine is irrelevant in this process.
I'd start here: Planning a Windows Hello for Business Deployment.