feat : 웨이팅 생성 로직 구현 #26
Conversation
hyun2371
requested review from
kkangh00n and
dlswns2480
and removed request for
kkangh00n
| ALREADY_CANCELED_WAITING("이미 웨이팅을 취소하였습니다."), | ||
| EXISTING_MEMBER_WAITING("이미 회원이 웨이팅 중인 가게가 존재합니다."), | ||
| SHOP_NOT_RUNNING("가게가 영업시간이 아닙니다."), | ||
| INTERNAL_SERVER_ERROR("내부 서버 오류입니다."); |
There was a problem hiding this comment.
ExceptionHandler 구현 시 기타 Exception을 handling할 때 사용하려고 했습니다!
| int waitingNumber, | ||
| int waitingOrder |
There was a problem hiding this comment.
api 스펙 바뀐것은 pr 내용에도 넣어주시면 감사하겠습니다!
근데 이 둘이 각각 정확히 어떤 걸 의미하는건가요??
There was a problem hiding this comment.
PR 수정했습니다~
waitingNumber는 웨이팅 고유 번호(불변)이고, waitingOrder는 웨이팅 순서(멤버 입장에 따라 1씩 차감)입니다!
| public Member getMemberEntity(Long memberId){ | ||
| return memberRepository.findById(memberId).orElseThrow( | ||
| ()-> new NotFoundCustomException(NOT_EXIST_MEMBER) | ||
| ); | ||
| } | ||
|
|
||
| public Shop getShopEntity(Long shopId){ | ||
| return shopRepository.findById(shopId).orElseThrow( | ||
| () -> new NotFoundCustomException(NOT_EXIST_SHOP) | ||
| ); | ||
| } |
There was a problem hiding this comment.
퍼사드 클래스인데 각 메소드에서 존재여부만 파악해서 여러 로직을 조립하는 과정이 없는데 퍼사드인 이유가 있을까요?? 즉, 퍼사드를 사용하는 측에서 shop의 존재여부를 알고 싶어 호출을 하면 여기선 하위 시스템들을 호출, 조립하여 응답을 하는게 아니라 여기서도 존재여부 결과만 리턴해주는 것 같습니다!
그리고 회원이 로그인을 통해 들어오는데 회원의 존재여부를 파악할 필요가 있을까요??
| Member member = waitingFacade.getMemberEntity(1L); | ||
| Shop shop = waitingFacade.getShopEntity(shopId); |
There was a problem hiding this comment.
이 부분에서 퍼사드를 사용하는 부분이 같은 클래스내에서 로직을 메소드로 따로 빼는거랑 어떤 차이가 있는건지 잘 모르겠습니다!
There was a problem hiding this comment.
단순 변수명 변경이기에, 커밋 유형이 style이면 어떨까 싶습니다~
| Member member = waitingFacade.getMemberEntity(1L); //member, shop 아이디 임시 1L | ||
| Shop shop = waitingFacade.getShopEntity(shopId); | ||
|
|
||
| // shop 영업 중인지 검증 | ||
| shop.validateIfShopOpened(LocalTime.now()); | ||
|
|
||
| // 기존 waiting이 있는지 검증 | ||
| validateIfMemberWaitingExists(member); | ||
|
|
||
| // 대기 번호 생성 | ||
| int waitingNumber = (waitingRepository.countByShopAndStatusAndCreatedAtBetween(shop, | ||
| PROGRESS, START_DATE_TIME, END_DATE_TIME)).intValue()+1; | ||
|
|
||
| // 대기 순서 생성 | ||
| int waitingOrder = (waitingRepository.countByShopAndCreatedAtBetween(shop, | ||
| START_DATE_TIME, END_DATE_TIME)).intValue()+1; | ||
|
|
||
| // waiting 저장 | ||
| Waiting waiting = WaitingMapper.toWaiting(request, waitingNumber, waitingOrder, member, shop); | ||
| Waiting savedWaiting = waitingRepository.save(waiting); |
There was a problem hiding this comment.
Facade 패턴을 이용한다면, Service에 있는 이 로직들이 Facade에 들어가야 된다고 생각합니다!
There was a problem hiding this comment.
넵! 퍼사드 패턴에 대해 더 공부한 다음 수정해보겠습니다!
hyun2371
force-pushed
the
feat/#10/waiting-api-1
branch
from
ad2d0ba
to
7df18a6
Compare
⛏ 작업 상세 내용
웨이팅 고유 번호, 웨이팅 순서 필드 추가
서비스 로직 내에서 두 필드 값 대입
필드 추가에 따른 API 응답 수정
{ "shopName" : "shop1", "waitingNumber" : 133, "waitingOrder" : 23 "memberName" : "member1", "date" : "2023-12-31 19:12", "peopleCount" : 4 }가게 영업 시간 필드 추가
서비스, 레포지토리 테스트 코드 작성
restDocs 생성을 위한 컨트롤러 단위 테스트 작성
baseEntity 필드명 수정
📝 작업 요약
☑️ 중점적으로 리뷰 할 부분