feat: 유저 알람 설정

[devmizz]

📌 Related Issue

🚨 해결하려는 문제가 무엇인가요?

• 유저 알람 설정 기능
• 유저 서비스 레이어 리팩토링

⭐️ 어떻게 해결했나요?

유저 알람 설정

• 유저가 알람을 설정하는 테이블을 별도로 분리하여, 추후에 알람 기능이 세분화 되더라도 컬럼 추가를 통해 대응이 가능합니다.
• 추후에 디바이스 별로 알람 설정이 상이하게 가능하다고 한다면, deviceId 필드를 추가하면 됩니다.

유저 서비스 레이어 리팩토링

• 기존에는 AuthService와 AuthAdminService로 분리되어 있었습니다.
• AuthService에서 회원가입과 로그인 등을 관리함에 따라 비대해졌습니다.
• AuthService와 AuthAdminService에 회원가입 로직이 동일하게 있어, 중복 코드가 발생했습니다.
• 이러한 문제를 해결하기 위해 회원가입(SignUpService)과 그 외 인증(UserAuthService) 기능으로 분리하였습니다.

🤔 어떤 부분에 집중하여 리뷰해야 할까요?

🗒️ 참고자료

RCA 룰

• R: 꼭 반영해 주세요. 적극적으로 고려해 주세요. (Request changes)
• C: 웬만하면 반영해 주세요. (Comment)
• A: 반영해도 좋고 넘어가도 좋습니다. 그냥 사소한 의견입니다. (Approve)

[Park-Young-Hun]

러프하게 보고 의견내는거긴 한데요! "/v1/alarms" 이렇게 alarm을 하나의 자원으로 명시하기보단 "/v1/users/{userId}/settings" or "/v1/users/settings" 이렇게 하고 PATCH로 설정 값 변경하면 어떨까요?
알람 설정말고도 다른 설정 값들이 추가될 수도 있고요!

[devmizz]

@Park-Young-Hun

말씀주신 부분은 이해되고, 추후에 알람 기능에 한하여, 알람이 세분화 된다면 그때는 PUT으로 body를 항상 받는 형태로 가져가고자 합니다!

다만, 세팅을 전체적으로 묶는 건 기피하고자 합니다.
세팅 전체를 단일한 PUT 메서드로 제공하는 경우, 설정 기능이 고도화되면 될수록 점차 body가 커집니다.
그에 따라 필드가 2,30개 되는 건 순식간이더라고요.
그래서 개인적으로 애초에 너무 큰 단위로 여겨질 수 있는 '설정' 단위로 놓는 것은 기피하는 편입니다.
물론, 개인마다 판단의 기준이 다르겠지만요!

[Park-Young-Hun]

수고하셨습니다 :)