[REFACTOR] User 리팩토링 #65
Description
♻️ 리팩토링의 목포가 무엇인가요?
유지보수 및 확장성, 그리고 읽기 쉬운 코드
✅ 작업 상세 내용
Controller
- API endpoints들 naming 수정 (space가 적절한 부분에는 '-' 사용, 어디어디로 묶인다의 의미가 적절한 부분에 '/' 사용
- DTO 수정 (1. UserBrief 등 여러 dto의 이름에서 오는 복잡함 제외. 2. 하나의 DTO class로 여러 경우를 handling할 수 있게. 3. Request의 경우 함수 명 + request로 dto 이름 통일함)
- validation Valid annotation 사용해 진행하기 + userService에서 validation 제외 (validation은 controller에서만)
- validation 실패 시 대비해 exception handler 수정
- token 포함한 Cookie 생성 및 response에 넣는 등 단순 작업은 util object로 이동시킴 (controller 최대한 단순화)
- token의 isSecure 다시 한 번 재검토하기 (이해를 제대로 못한 듯)
Service
- validation 부분 제외
- request를 통으로 service에서 받아와서 처리함 (이유: request의 내용이 바뀌면 service단만 바꾸면 됨 + 더 깔끔함)
- 하나의 signup 함수에서 merge되는 경우, local signup인 경우, social signup인 경우, admin signup인 경우를 다 handle함
- merge되는 경우 handle 위해 DTO에 isMerged 추가
- signIn도 마찬가지
- Admin signup, ResetDB에 비밀번호 설정 (.env) 이용
- EmailService에서 sendCode 등 RedisService나 Repository access 필요한 함수 제외, 단순 이메일 보내는 함수만 남겨둠 (이유: separation of concerns, userService가 business logic의 대다수를 담고 있기를 바랬음, EmailService가 user data를 다루기에 적절한 naming이 아님 )
- isMerged 대신, 뭐가 merge되었는지 알려주는 필드로 진행하기
- Exception 그때그때 string 넣지말고, 한 파일로 모아서 type으로 만들어 관리하기 (ex : UserNotExistsByLocalIdException)
- Http Status code 알맞게 수정
- 미완성 함수들 마무리하기 (비밀번호 재설정 메일 보내기, 비밀번호 재설정 등)
- .env 이용한 비밀번호 검토
Persistence
- Single table inheritance 삭제 및 Role-based access control (Role enum) (고민하다가 다시 바꿨습니다)
- Prepersist 통한 constraint 적용 (로그인 수단 둘 중 하나는 있어야 함)
- Prepersist 통해, user인데 post가 있는 경우 등 모순 있을 시 에러 띄우기
- Prepersist 에러 핸들링
전반
- 네이밍이 길어지더라도 명확함을 우선시하여 네이밍 대다수 수정하였습니다. (ex) sendCode -> sendSnuMailVerification
- separation of concerns (controller 는 validation 및 api 엔드포인트 관리, service는 business logic, utils는 domain layer와 무관 등)를 우선시하였습니다
- 커멘트 통해 코드들을 범주로 묶어 구분하려 했습니다.
- 타 부분과 sync 맞추기
- 새롭게 추가된 feature 개발
- api 문서 수정
- merge
📝 참고 자료
No response