[#25] 결제관련 entity 생성 및 설계 #38
Conversation
- 조인 전략으로 상속구조 매핑 - Payment 관련 Entity, Repository 생성:
| @Test | ||
| public void testPayment() throws Exception { | ||
|
|
||
| AccountDto buyerAccountDto = AccountDto.builder() | ||
| .accountRole(Set.of(AccountRole.USER)) | ||
| .address(new Address("a", "b", "c")) | ||
| .email("[email protected]") | ||
| .nickname("buyer") | ||
| .phone("01012341234") | ||
| .password("pass") | ||
| .build(); | ||
| AccountDto buyerDto = accountService.saveAccount(buyerAccountDto); | ||
|
|
||
| mockMvc.perform(post("/api/orders/buyer/payment") | ||
| .header(HttpHeaders.AUTHORIZATION, getAccessToken(buyerAccountDto)) | ||
| .contentType(MediaType.APPLICATION_JSON_UTF8) | ||
| .accept(MediaTypes.HAL_JSON)) | ||
| .andDo(print()); | ||
| } | ||
|
|
There was a problem hiding this comment.
상속관계 매핑 테스트한다고 임의로 넣은코드가 커밋됐네요~ 다음 커밋에 수정하겠습니다
|
코드는 몇줄안되지만.. |
|
전체적으로 보았을때 추상화에 대한 아이디어는 좋았지만 이는 "동작"에 대한 추상화입니다. 저장하는 데이터는 결제테이블이 하나만 있는게 좋을 것 같아요. (결제수단 n개만큼 테이블을 만들면 jpa외의 툴을 사용할때 상당히 복잡할겁니다) |
|
그리고 approve된 PR들은 머지하셔도 됩니다 |
- Payment 관련 Entity 생성 - Payment 관련 Dto, Cotroller, Service, Repository 생성 - Service 레이어 추상화 - TODO : 전략패턴 적용
| public PaymentDto payForOrder(PaymentDto paymentDto, Long orderId) { | ||
| public Payment payForOrder(PaymentDto paymentDto, Long orderId) { |
There was a problem hiding this comment.
기존 주문관련 로직들이 DTO가아니라 Entity를 리턴하도록 코드 작성했는데,
이후에 한번에 은닉화 적용하기위해 임시적으로 Entity를 리턴하도록 했습니다~
|
이번에 고민하는 부분은 각 결제 방법마다 다른종류의 정보들을 Client에서 어떻게 받아올지가 고민이었습니다. 시도해본 방법
위 3가지 정도 생각해봤는데 어떤게 적절한지, 다른 방법이 더 합리적인지 궁금합니다~ |
|
일단 이쪽부분은 클래스 다이어그램으로 그려보시면 좋을 것 같습니다. 그것을 바탕으로 얘기해본 다음 최종 클래스다이어그램을 위키에 올려봐도 좋을 것 같고요, 요청마다 다른 응답을 내려주는 부분은 거기서도 상속을 이용해보시면 좋을 것 같습니다. 추상화를 해두면 클라이언트에 분기할 필요없이 그냥 내려줘도 됩니다. 어차피 JSON으로 변환되니까요~ |
- 각 결제수단 DTO 들이 PaymentDto 를 상속받게 변경 - CashPaymentService 결제 메서드 수정 - TODO : 공통 부분 추출
- 결제완료 메서드 -> OrderService 로 이동 - 각 결제별 핵심로직은 PaymentService 로 추상화 - Factory 로직을 분기 -> Map 으로 변경 - DTO 와 Adapter 로 책임 분리
- 결제완료에 대한 테스트 코드 - PaymentDto 관련 수정 - 결제완료에서 결제정보를 세터를통해 수정하도록 변경
| .payment(paymentDto.toPaymentEntity()) | ||
| .build(); | ||
| } | ||
| public static PaymentDto toDto(CashPayment cashPayment) { |
There was a problem hiding this comment.
이거는 from이나 fromEntity가 낫지 않을까요? 사용할 때 모양이 PaymentDto.toDto()의 모양이 되는데 PaymentDto를 다시 Dto로 변환해주는 역할로 보일 수 있을 것 같습니다
| break; | ||
| default: | ||
| throw new IllegalArgumentException(); | ||
| public PaymentService getType(PaymentType paymentType) { |
There was a problem hiding this comment.
Type을 가져오는게 아니라 Service를 가져오는것이므로 이름을 적절하게 바꿔주면 좋을 것 같습니다~
| /* 주문이 완료되면 아이템의 전체 재고에서 주문수량만큼 빼주어야한다. */ | ||
| //TODO : N+1문제 -> 벌크호출 | ||
| orderItems.forEach((orderItem) -> | ||
| itemService.decrementStock(orderItem.getItem().getId(), orderItem.getQuantity()) |
There was a problem hiding this comment.
이것도 TODO로 두기보다는 이 이슈에서 바로 해결해주면 좋을 것 같습니다~ 블로그 포스팅거리도 될 것 같네요
[#39] 결제완료에 대한 테스트 코드추가
결제하는 방법에 3가지(카드, 계좌이체, 모바일)
3개의 클래스는
Payment라는 부모 (추상)클래스를 상속받고있음 -> JPA 조인전략으로 상속관계 매핑Client 측에서 결제정보를
@RequestBody Payment payment로 가져옴상위 타입에 PaymentRepository를 사용해서 DB에 저장