# 한태현_Spring
### src.backend.payment
- 충전 서비스
- 링크 & 위치
- [com.steam.payment.service.ChargeService 전체](https://github.com/STOVE-Milk/steam-clone/blob/develop/src/backend/payment/src/main/java/com/steam/payment/service/ChargeService.java)
- 로깅을 Service 단에서 하는데, 개인적으로 비즈니스 로직이 눈에 잘 안들어옵니다. 로그의 내용이 각자 다 달라 공통적인 모듈로 빼기가 애매하게 느껴지는데, 지금 방식에서 개선하는 방법이 있을까요?

- 충전 & 구매 로그 객체
- 링크 & 위치
- [com.steam.payment.entity.mongodb ChargeLog & PurchaseLog](https://github.com/STOVE-Milk/steam-clone/tree/develop/src/backend/payment/src/main/java/com/steam/payment/entity/mongodb)
- ChargeLog와 PurchaseLog의 비슷한 부분이 많고, Double totalPrice, 충전/결제 대상에 해당하는 객체가 다릅니다. Document 객체들도 내용적으로 비슷한데, 이것을 통합하거나, 다형성의 측면에서 개선하는 방법을 알고 싶습니다. 앞서 상속을 이용해 보려다가 실패했습니다.

### src.backend.membership
- 친구 관련 서비스
- 링크 & 위치
- [com.steam.membership.service.FriendService](https://github.com/STOVE-Milk/steam-clone/blob/develop/src/backend/membership/src/main/java/com/steam/membership/service/FriendService.java)
- 전체
- payment 서버의 경우 Repository로 데이터를 불러왔을 때, 데이터가 없을 경우 Throw로 처리를 했었고, Throw에 대한 자원 소모 피드백을 받았습니다. 그래서 if문을 이용해 예외상황을 errorBody로 만들어서 return하는 방식으로 바꾸었는데, 이 방식을 말하신 건지 궁금합니다.
- 변경되면 안되는 객체나, 메소드 파라미터에 최대한 final을 붙이려고 했습니다. 습관이 제대로 안들여져서 빼먹은 부분도 많은 것 같은데, 오히려 혼동을 줄 것 같아서 걱정됩니다. + 이런 습관을 들이는 것이 괜찮을지 궁금합니다.
- 토글 상황
- 상세 위치 : 155줄 rejectFriendRequest
- 친구 신청 거절 시 거절할 request가 없을 경우는 굳이 예외로 return 하기보다, 아무 작업을 하지 말고 성공을 return 해줘도 될 것 같은데, 어느 것이 더 나을까요?