[FEATURE] 회원가입 API

[mungmnb777]

Issue ticket link and number

• [FEATURE] 회원가입 API #10

Describe changes

• 회원가입 API를 구현하였습니다.
• 회원가입에 필요한 이메일 중복 체크, 닉네임 중복 체크 API를 구현하였습니다.
• ErrorResponse 클래스의 Json 직렬화가 되지 않는 버그를 수정했습니다.

Notification for Reviewer

• 회원가입 시 전용 재료를 인벤토리를 넣을 때, stockQuantity를 10억을 INF로 정하여 넣었습니다. 그런데 굳이 전용 재료를 인벤토리에서 관리할 필요가 있을까라는 생각이 들었습니다. 인벤토리에 전용 재료를 넣은 후, 재고를 늘리거나 올릴 일이 없다고 생각합니다. 그래서 인벤토리에 전용 재료를 삽입하는 로직을 뺄까 생각하는데 어떻게 생각하시나요?

요약

1. 회원가입 시 인벤토리에 전용 재료를 넣는다.
2. 회원가입 시 인벤토리에 전용 재료를 넣지 않는다.

감사합니다.

[github-actions]

코드 리뷰 요청합니다 🙆 @h-beeen

[h-beeen]

회원가입 시 인벤토리에 전용 재료를 넣는다.
회원가입 시 인벤토리에 전용 재료를 넣지 않는다.

회원 가입시 인벤토리에 전용 재료를 넣지 않는 로직으로 작성하는 것에 대해 한표를 던지고 싶습니다.

1. 10억이라는 큰 INF 로 관리하는 것은, 현실적으로 절대 터질 일이 없지만, 이론적으로 불안정한 설계라는 의견을 드리고 싶어요.
2. 만약 유저가 회원가입 한 이후, 신규 재료가 추가된다면? 해당 유저의 떡국 재료를 조회하는 과정에서 NPE 발생 이슈도 있을 것 같아요.

회원가입후, 최초 재고 및 인벤토리를 어떻게 관리해야 할 지 조금 고민해봐야 할 것 같아요!

[github-actions]

성공적으로 Merge 되었습니다. Shout out to @h-beeen 😉

[h-beeen]

이 부분을 이런 방식으로 설계하신 이유가 있을까요?

[mungmnb777]

Member는 SimpleMember와 OAuthMember로 나누어지게 됩니다.

각각 Member를 상속한 엔티티로 관리되는데, 리포지토리도 상속 관계를 따라서 구현하기 위함이었습니다.

이렇게 하면 추상 메서드의 중복을 줄일 수 있으리라 생각해서 위와 같이 설계하였습니다