Hmm short answer to a long question, but I see the pattern as follows
Rule 1 : Domain Objects should have a single Aggregate Root
Rule 2 : Aggregate Roots shouldn't be too big, Split things up into Bounded Contexts
Problem : Aggregate Roots soon become too big and there is no clear way to draw a line between the various Domain Models in them
Solution : Domain Services. Create interfaces you can inject into Domain Models that allow them to do things outside of their Domain Context or Aggregate Root.
So I think I would say that your examples are just normal Services/Repositories etc, IDatabaseRepositoryForStoringUsers or IGenericHashingCode
A Domain Service enables communication between Bounded Contexts. ie
User.UpgradeAccount(IAccountService accountService)
{
accountService.UpgradeUsersAccount(this.Id);
}
Where Users and Accounts are in separate Aggregate Roots/Bounded Contexts.
If the User and Account are in the same Aggregate Root you should of course be able to do:
User.UpgradeAccount()
{
this.MyAccount.Upgrade();
}
I'm not totally clear from your question how you are integrating the nTier Application/Infrastructure stuff and the Module stuff. Obvs you don't really want any cross referencing between Bounded Contexts, so you would put your Domain Service Interfaces in their own Module which doesn't reference any other Bounded Context. limiting you to exposing base value types, or perhapse DTOs only