Where should I hash my password in a DDD based architecture (Onion Architecture)?

Question

I'm trying to figure out the best place to hash my password for Authentication in my architecture. This is my request flow:

MVC3->MembershipProvider->AccountService->UserRepository->NHibernate->Database

I'm torn between hashing at the service level vs the repository level. I'm seeing advantages to both, but does anyone know the standard place to take care of this? I'm storing the hash password in the database.

Answer 1

If we are talking strictly DDD (Domain Driven Design), then the password hashing should be handled by the User (Domain Entity or Aggregate Root). Pass the user input (password) from controller down to AccountService, have AccountService load/create new user and call a method on user that will hash password. if you need an example, take a look at this url: Example of User in MVC3 app

Answer 2

DDD is not a top-level architecture. You apply it within a bounded context. There can be many bounded contexts in a system, some of them DDD, some not.

Whatever your core domain is about, authentication doesn't belong to it. It's a generic domain at best, an already solved problem. That should reside in an application layer only - that's just how your GUI protects the access to the domain. No fancy DDD building blocks. No repositories, no services. Just make your membership provider talk to NHibernate directly or even raw ADO.NET. Or maybe you don't need a custom one. Doesn't SqlMembershipProvider fit your needs?