Authentication and User Tasks

Question

I'm looking at developing a system (primarily web based) that has a clearly defined domain.

Parts of the domain include entities like Diary, Booking, Customer, etc.

However I created another entity called User whose intention is for authentication and authorization only (it seemed wrong to contaminate the Customer entity with data specific to authentication). I figure this isn't part of the domain of "making bookings", but specifically this should belong to the application layer (I'm trialling a hexagonal architecture).

I'm accessing my repositories using interfaces in my domain model and wiring them up to my persistence layer using IoC.

My questions are this:

• Should I put the authentication/authorization code in the application and keep it out of the domain?

• If I do keep it out of the domain, should I put the interface for the UserRepository in the application layer also (I think this would make sense)?

• If I do keep it out of the domain, I will end up with entities also in the application layer called User etc. This seems wrong.

What are people's thoughts?

[EDIT]

I've gone for a solution that takes a bit from both answers, so thanks for answering and I've +1'd you both.

What I've done is put the authentication/authorisation code in a subdomain (secondary adapter), in a separate project, and because it requires access to it's own persistence (a few collections in a separate RavenDB database), I'm including these straight into the separate project keeping them separate from the main persistence layer.

Answer 1

Should I put the authentication/authorization code in the application and keep it out of the domain?

No, you should keep authentication/authorization code out of the core domain. It belongs to a generic subdomain.

If I do keep it out of the domain, should I put the interface for the UserRepository in the application layer also (I think this would make sense)?

You could keep UserRepository in the domain layer, but you'd better keep the "access and identify" subdomain and the "making bookings" core domain separated with each other. You could use different packages or namespace.

The next challenge is how to integrate these two domains. In my humble opinion, you may:

1. Expose a DomainService from "access and identify" subdomain to the application layer for making authentication/authorization decisions.
2. Sometimes we have to find out who made Diaries and Bookings, in this case, use the identifier of the User is enough. Other information such as "favorite tags" or something like that is usually not needed in "making booking" core domain.

Answer 2

Authentication is a generic domain, not a part of your domain. So, yes, keep it in some component in application layer.

Not all parts of your system should follow DDD patterns. You can use UserRepository if you see a benefit for this but I would use just some already available component/popular library of your environment like MembershipProvider in ASP.NET world.