[Refactor] AuthorizationService — 도메인 Service의 SCOPE 의존 제거 및 Strategy 패턴 도입

[changuii]

📝 개요

배경

현재 AuthorizationService는 도메인 Service가 권한 검증의 방식(SCOPE)까지 직접 지정하는 구조로 설계되어 있다.

현재 구조

도메인 Service
  → "festival scope로 검증해" (SCOPE를 직접 지정)
  → AuthorizationService (SCOPE별 분기 처리)

// AnnouncementService — 도메인 Service가 SCOPE를 결정하고 있음
validateFestivalCommandAccess(festivalId);                          // SCOPE: FESTIVAL 직접 지정
validateFestivalCommandAccess(Announcement.class, announcementId);  // SCOPE: ANNOUNCEMENT → FESTIVAL resolve

접근 주체(WHO), 검증 범위(SCOPE), 검증 방식(HOW)이라는 3개의 변경 축이 하나의 클래스에 뒤섞여 있어 어느 한 축이 변경될 때마다 기존 코드를 수정해야 한다.

문제 1 — 새 역할 추가 시 기존 코드 수정 불가피 (OCP 위반)

PLACE_ACCESS 역할이 추가되었을 때 기존 festival 검증 메서드에 분기가 삽입되었다.

// PLACE_ACCESS 추가 전
public void validatePlaceCommandAccess(Long placeId) {
    if (isOrganizer || isStaff) {
        // festival 권한으로 검증
    }
}
// PLACE_ACCESS 추가 후 → 기존 코드 수정 불가피

public void validatePlaceCommandAccess(Long placeId) {

if (isOrganizer || isStaff) {

// festival 권한으로 검증

} else if (isPlaceAccess) {

// place 권한으로 검증 — 기존 메서드에 분기 추가

}

}

문제 2 — 도메인 Service가 검증 세부사항을 알고 있음 (SRP 위반)

도메인 Service는 "내가 무엇에 접근하는가"만 알아야 하는데, 현재는 "어떤 SCOPE로 어떻게 검증할지"까지 알고 있다.

레이어	알아야 하는 것	현재 알고 있는 것
도메인 Service	TARGET (접근 대상)	TARGET + SCOPE + 검증 방식
AuthorizationService	subject 결정, Strategy 탐색	subject 결정 + 모든 검증 로직

문제 3 — 단건/복수 중복 (DRY 위반)

실질적으로 동일한 로직임에도 메서드가 이중으로 존재하거나 외부에서 분기한다.

validateFestivalCommandAccess(festivalId);                   // 단건
validateFestivalCommandAccess(Announcement.class, ids);      // 복수 — 로직은 동일

문제 4 — 불필요한 의존 (ISP 위반)

PlaceService는 place 관련 검증 메서드만 필요하지만, festival/organization 관련 메서드까지 포함된 거대한 서비스에 의존한다.