Is authentication a concern of my domain or of my application?

Question

I'm trying to design the authentication of my web application in an object oriented manner. Is this a concern of my domain in which case I would have something like this:

$user->authenticate($authenticator);
$user->login($authenticator);

Where $authenticator is an interface to my authentication service.

Or would this be a cross cutting concern and I would do it the other way around.

$authenticator->authenticate($user);
$session->setUser($user);

The first way seems more "OO" to me, since I don't have to ask anything from my user object...it passes the information the authenticator needs. But it feels like I'm "polluting" my domain in a certain respect...logging in is not a business requirement of my application...it is a side effect from the fact that I need a method of authentication to protect my application.

Answer 1

IMHO passing an Authenticator is bad OO. Why should a user understand how to authenticate itself? It's a user it doesn't even need to know what an authenticator is. Also, passing an authenticator seems strange to me unless you plan on having different ways of authenticating a user thus having a need to pass different types of authenticators to your user. You make it seem like authentication isn't a major part of your application so I doubt you will have more than one way of authenticating a user.

I think your second approach makes more sense although still seems like overkill to me. My favorite framework is symfony and they have a great plugin called sfGuard that handles authentication. Take a look at the source code of the plugin and see if it gives you any inspiration.

Answer 2

Coupling

$user->authenticate($authenticator);
$user->login($authenticator);

Inversion of control

$authenticator->authenticate($user);
$session->setUser($user);

Coupling is bad, inversion is good. Go with the later.

Answer 3

Unless your Domain includes authentication as a central concept, I would say that it's a cross-cutting concern and not part of the Domain Model.

Most developers write business applications that model something entirely different than software security. Authentication is a very important part of many applications, but really has nothing to do with the Domain itself.

That doesn't mean that you can't deal with authentication in an object-oriented way.

In Domain-Driven Design terminology, the business concept you model is part of your Core Domain while you could choose to implement authentication and other security concepts in a Generic Subdomain.

I can't help with the php-specific things, but in .NET, security is pretty much something that's just handled by the platform if you do it right. Here it's a truly cross-cutting concern by implementation, so that's how it's done elsewhere (FWIW).