Facade 패턴, SRP 원칙 기반으로 리팩토링을 해보자
들어가며 현재 서비스중인 AuthService가 387줄의 거대한 God Object로 성장해버렸다. 로그인, 회원가입, 소셜 로그인, 이메일 찾기, 비밀번호 변경 등 인증 관련 모든 기능을 한 클래스에서 처리하다 보니 테스트도 어렵고 수정할 때마다 긴 코드를 찾아봐야 하다보니 유지보수에 있어서 너무 불편했다. 이를 SRP 원칙에 따라 3개 서비스로 분리하고, Facade 패턴으로 재구성한 과정을 기록했다. 문제 상황 God Object가 된 AuthService AuthService - 387줄 - 의존성: 11개 - 담당 책임: 6가지 1. 로그인/로그아웃 (토큰 관리) 2. 회원가입 (검증 + 외부 API + DB 저장) 3. 소셜 로그인 (카카오/구글/네이버) 4. 이메일/전화번호 찾기 5. 이메일 인증 발송/확인 6. 비밀번호 변경 한 클래스가 6가지 책임을 가지고 있고 명백한 SRP 위반이다. ...