[feat] 소셜 로그인 회원가입 설문 및 추가 정보 등록 로직 통합 및 설문 question 필드 제거

[iamseojin]

이슈

• [WT-41] 소셜 로그인 후 회원 추가 정보 및 설문 통합 등록 기능 구현 #65

최종 변경 사항 (요약)

• POST /api/v1/signup/register 단일 호출로 추가 정보 + 설문을 함께 처리
• 처리 흐름을 MemberSignupService로 일원화
• 설문까지 저장 완료 시 additionalDataChecked=true로 상태 마킹
• Survey 엔티티의 question필드/검증 로직 제거
• Member 생성자에서 name/email/oauthId 초기화 누락 버그 수정
• DTO 정리: SignupWithSurveyRequestDto의 불필요한 @Setter 제거, DTO 클래스 레벨의 불필요한 @Valid 제거

상세 변경 및 근거

1. /signup/register 통합 처리 MemberSignupService로 일원화

• 무엇을 바꿨나

  • 컨트롤러가 퍼사드 호출 대신 memberSignupService.registerWithSurvey(email, req)만 호출
  • 서비스 내부에서 다음 세 가지 과정을 하나의 트랜잭션(@transactional) 으로 수행
    • 추가 정보 저장,
    • 설문 N개 저장
    • additionalDataChecked = true

• 왜 바꿨나

  • 원자성: 중간 단계 실패 시 전체 롤백 → 상태 불일치 방지
  • 트랜잭션 경계 명확화: 쓰기(use case) 책임을 한 서비스가 소유 → 일관성 있는 변경 단위
  • 의존성 방향 단순화: 서비스-서비스 간 오케스트레이션을 제거하고, 애플리케이션 서비스가 레포지토리를 직접 사용
    → 순환 의존 가능성 축소, 테스트/리뷰 포인트가 한 곳으로 집중

2. 설문 완료 시 additionalDataChecked = true

• 무엇을 바꿨나

  • 설문 저장이 성공적으로 끝나면 회원 엔티티에서 markAdditionalDataChecked() 호출

• 왜 바꿨나

  • 이후 소셜 로그인 시 추가 정보/설문 입력 필요 여부를 O(1)로 판별
  • 불필요한 가입 플로우 재진입 방지 → UX 개선 및 서버 부하 감소

3. Survey 엔티티에서 question 제거

• 무엇을 바꿨나

  • 컬럼·DTO·생성 메서드·검증 로직에서 question 삭제

• 왜 바꿨나

  • 질문 문구는 클라이언트에서 상수로 관리 → DB 중복 저장 불필요
  • 스키마 단순화, 저장 공간 절감, 로직 복잡도 감소

4. Member 생성자 초기화 누락 버그 수정

• 무엇을 바꿨나

  • Member(String name, String email, String oauthId) 생성자에서 세 필드 모두 정상 세팅

• 왜 바꿨나

  • 누락으로 인해 email = null INSERT 시 NOT NULL 제약 위반 발생 및 신규 회원 기본 정보 저장 오류 문제 발생

5. request DTO 리팩토링

• 무엇을 바꿨나

  • @Setter 제거 → 불변성 강화
  • 내부 필드 @Valid 제거

• 왜 바꿨나

  • Setter 제거: DTO는 입력 모델이므로 생성 시점 이후 변경 불가가 안전, Jackson은 생성자/프로퍼티 바인딩으로 매핑 가능
  • @Valid 제거: @Valid는 컨트롤러 메서드 파라미터 검증에서 의미가 있으며 DTO 클래스 자체에는 붙일 필요 없음

** pr 리뷰를 통한 변경사항 (Facade → 일원화)**

• 신규 회원의 설문 응답 및 추가 정보 통합 기능에 쓰이는 서비스 계층 간의 의존성을 단방향 의존 패턴으로 풀고자 퍼사드 패턴을 사용
• 퍼사드가 도메인 서비스들을 다시 오케스트레이션하면서 트랜잭션/변경 책임 분산, 서비스 간 호출 그래프 길어짐
• 애플리케이션 서비스(=MemberSignupService)가 해당 쓰기 use case의 단일 진입점이 되도록 일원화
• 의존성 방향성 단방향 유지

[LEEDONGH00N]

Setter는 제거해주세요

[LEEDONGH00N]

@Valid는 컨트롤러에서 메서드 파라미터 검증할 때 사용하는 어노테이션이라서 여기서는 사용하지 않아도 됩니다.

[LEEDONGH00N]

현재 파사드 패턴을 적용하신걸로 보이는데, 이보단 MemberSignUpService에서 MemberRepository와 SurveyRepository를 사용해 정보를 저장하는걸 추천드립니다.

[iamseojin]

좋은 방법이네요

[LEEDONGH00N]

다른 Service에서 memberRepository.findByEmail(email) 또는 loadMemberOrThrow 메서드를 참고해서 수정해주세요

[iamseojin]

적용했습니다