Should the domain layer be dependent on NHibernate in this scenario?
From a purist perspective: no it should not. The domain layer shouldn't be carrying around a bunch of dependencies on your persistence solution. "UnitOfWork" and "Transaction" are not part of the ubiquitous language of most business domains.
From the onion perspective: your dependency is pointing the wrong way. Instead of adding an NHibernate dependency, you can put an agnostic service provider interface into your module, and then pass an NHibernate implementation of the agnostic interface to the ports that need it.
In practice: I doubt that the DDD police are going to come after you.
Domain Services can access the database
Not quite right. Implementations of
Domain Services can access the database. The interface, used by the domain model, just expresses the service in the domain language. The implementation is going to be relying on other application and infrastructure services - ie, other service providers of interfaces that it defines, and it's turtles all the way down.
The thing that actually talks to the NHibernate is probably going to be an infrastructure service.
In other words, your composition root is probably going to look something like
NHibernateThing nhibernate = ...
DomainServiceImpl.Adapter infrastructure = InfrastructureService.using(nhibernate)
DomainService service = DomainServiceImpl.using(infrastructure)
where you are wiring each adapter into the appropriate port in turn.
Reread Parnas; at a fundamental level, NHibernate is the result of a decision, and you want module boundaries in place that separate the pieces that depend on that decision from the pieces that do not. That makes it easier to change when the time comes.
But - you should be balancing this against the risk of change; if NHibernate is always going to be part of your solution, then you shouldn't be investing in decoupling it from your domain.