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.
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).