인증이 내 도메인 또는 신청서의 우려 사항입니까?

Question

나는 웹 응용 프로그램의 인증을 객체 지향 방식으로 설계하려고합니다. 이런 경우 내 도메인의 우려 사항입니까?

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

여기서 $ authenticator는 인증 서비스에 대한 인터페이스입니다.

또는이 것이 교차 절단 우려 일 수 있으며 주위를 다른 방법으로 수행 할 것입니다.

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

내 사용자 개체에서 아무 것도 묻지 않아도되는 첫 번째 방법은 인증 기관에 필요한 정보를 전달하는 것입니다. 하지만 특정 영역에서 도메인을 "오염"시키는 것처럼 느껴집니다 ... 로그인은 내 응용 프로그램의 비즈니스 요구 사항이 아닙니다 ... 내 인증을 보호하기 위해 인증 방법이 필요하다는 측면에서의 부작용입니다. 신청.

Answer 1

도메인에 인증이 핵심 개념으로 포함되어 있지 않는 한 도메인 모델과 관련이없는 것으로 간주됩니다.

대부분의 개발자는 소프트웨어 보안과 완전히 다른 모델을 작성하는 비즈니스 응용 프로그램을 작성합니다. 인증은 많은 응용 프로그램에서 매우 중요한 부분이지만 실제로 도메인 자체와는 아무런 관련이 없습니다.

그렇다고해서 객체 지향 방식으로 인증을 처리 할 수 ​​없다는 의미는 아닙니다.

이 Domain-Driven Design 용어로, 비즈니스 개념 당신이 모델의 일부입니다 귀하의 핵심 도메인 당신이 일반 하위 도메인에서 인증 및 기타 보안 개념을 구현하도록 선택할 수있다.

PHP 관련 작업은 도움이되지 않지만 .NET에서는 보안이 매우 중요합니다. 여기서는 구현에 대한 진정한 교차 관심사이므로 다른 곳에서 어떻게 수행되는지 (FWIW)에 대한 것입니다.

Answer 2

인증자를 전달하는 IMHO가 좋지 않습니다. 왜 사용자가 자신을 인증하는 방법을 이해해야합니까? 인증자가 무엇인지 알 필요가없는 사용자입니다. 또한 사용자 인증 방법이 다르므로 다른 유형의 인증 프로그램을 사용자에게 전달해야하는 경우를 제외하고는 인증 프로그램을 전달하는 것이 이상하게 보입니다. 인증이 응용 프로그램의 주요 부분이 아닌 것 같아서 사용자를 인증하는 방법이 여러 가지가 될지 의심 스럽습니다.

두 번째 접근법은 나에게 과도한 것처럼 보이지만 더 의미가 있다고 생각합니다. 내가 가장 좋아하는 프레임 워크는 symfony이며 인증을 처리하는 sfGuard라는 훌륭한 플러그인이 있습니다. source code of the plugin을보고 영감을 주는지 확인하십시오.

Answer 3

는

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

반전 제어

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

커플 링이 나쁜의 커플 링, 반전이 좋다. 나중에와.