[REFACTOR] 리팩토링 생각 #59
Description
📝 이슈 내용
추가하려는 기능에 대해 간결하게 설명해주세요
지금 너무 바쁘기도 하고 뭐가 정답이랄건 없어서, 프로젝트가 끝나고 한번씩 같이 고민해보면 좋을 것 같습니다.
API URL
저는 지도 도메인의 경우 API URL가 /stores/map/... 식으로 가는게 낫다고 생각하는데, 어떻게 생각하시나요?
환경 API의 경우 /environment -> /members/environment 식이 더 좋은 것 같아요. 환경 데이터가 결국 회원들의 데이터여서요!
회원 탈퇴의 경우 members/delete 는 정말 삭제를 의미하는 것 같아서 revoke, leave
도메인 의존 구조
현재 favorite, map 도메인은 Store 객체에 강하게 의존하는 상태입니다. 그래서 Menu, StoreImage 처럼 아예 Store 도메인 패키지에 넣는 것도 방법인 것 같아요.
현재 mapRepository 메서드들의 경우 가게를 조회하는게 끝이라서 가게쪽의 책임이고, storeRepository에 책임(메서드)들을 위임하도록 하는게 좋다고 생각해요.
시큐리티 - 인증 객체 및 권한 체크
전에 같이 얘기했던 UserDetail 구현체로 동현님이 만들어주신걸 잘 쓰고 있습니다만, 더 좋은 방식은 없을까(지원님이 말씀하신 MemberId 커스텀 어노테이션 등) 고민해보면 좋을 것 같습니다.
권한 체크도 @PreAuthorize 어노테이션을 통해 권한 체크를 하는 방법이 있다고 들었는데, 알아보면 좋을 것 같구요.
공통 응답 형식 및 글로벌 예외 처리 핸들러
컨트롤러들의 공통 관심사인 statusCode, message 등이 리터럴 값으로 들어가고 있어서 이 역할을 ApiResponse 부분에서 처리하면 어떨까 생각합니다.
그리고 글로벌 예외 처리 핸들러에서 잡는 예외가 한정적이고, 현재 나눠놓은 커스텀 예외 객체들과 예외 메세지 이넘 객체(ExceptionMessage)들을 나눠놓은 의미가 그렇게 크지는 않은 것 같아요. API 명세와도 관련 있는 부분인데, 예외가 발생했을 때 정확히 어떤 문제인지 알려주는게 더 좋다고 생각합니다.
테스트 코드 (원석)
서비스 메서드들에 대한 유닛 테스트
로깅 통일
AOP(LoggerAspect.java)를 통한 로그 공통 관심사를 최대한 한 곳으로 응집시키기
판매자 관리 페이지상의 가게 개수
현재는 가게가 1개라는 전제하에 관리가 이뤄지는 방식.
그러나.. 하나의 사업자 등록 번호에 여러 점포를 운영할 수 있다.
10개 점포를 운영하는 사장님의 입장에서는 회원가입을 10번 해야 함.
음... 근데 또 이걸 재고 등록하고 관리하는 사람은 직원일거다. 사장님 혼자 모든 점포 재고를 일일이 확인하긴 어려우니까.
그리고 지금 가게를 관리할 수 있는 페이지가 없는걸로 알고 있는데...
추후... 보류..
순환 참조 문제 (지원)
StoreQueryService-ReviewQueryService 간 의존관계가 양방향이어서 순환 참조되는 문제.
관리자 도메인 분리 (동현)
API URI에 /admin 포함시키고, Controller, Service.
인증 인가 여부 적용안된 API들
/api/maps/.... JWT가 없어도 작동함.
@PreAuthorized() 어노테이션이 제대로 동작하지 않는듯.
✅ 체크 리스트
- 배.동.석 프로젝트 스터디 진행하기
🛰️ 관련 요구사항
- 요구사항 타입 - 번호: ~~~~~