feat: member address management #44
Conversation
테스트 결제 요청을 위한 결제 위젯 UI 추가
webclint 사용을 위해 의존성 추가
webclint 사용을 위해 빈 등록 설정
엔드포인트 버전 관리 용이함을 위해 prefix 추가 설정 작성
기본 보안 설정 작성 및 모든 엔드포인트 승인
개발 환경에서 사용할 설정 프로파일 작성
toss 결제 비밀키 추가
인증 승인 요청 API 처리시 필요한 인증 헤더 발급기 구현
결제 승인 엔드포인트 구현
결제 승인 응답 및 요청 객체 구현
토스 결제 승인 PG 요청 엔드포인트 구현 및 예외상황 처리
토스 결제 승인 PG 응답 객체 구현
예외 추상화와 handler를 이용해 예외 응답 구체화
토스 결제 승인 예외에 대한 열거체 구현
토스 결제 승인 예외에 대한 열거체 구현
secret key를 추상 클래스로 이전
외부 API 실패시 복구를 위한 retry 설정
유일 order id를 발급하는 엔드포인트 구현
주문번호 발급 및 유일성 검증을 위한 repository 조회 및 api 조회 기능 구현
주문번호를 요청에 담을 수 있도록 수정
주문번호 조회 실패시 발생할 예외코드 구현
결제정보에 주문번호와 결제키 추가
테스트 ui를 위젯 UI로 수정
로컬환경에서 mysql 사용을 위해 포트포워딩
`Long`타입 검증 방식과 맞지 않는 검증 어노테이션 제거
repository 작성
공통 사용 열거체를 내부에서 외부로 이동
개발 편의를 위한 일부 메서드 구현
결제 요청에 경매 id 추가
테스트 편의를 위해 코드 수정
주소 API에서 제공하는 정보에 맞게 컬럼 수정
생성 위임 메서드 추가
주소 정보 응답 및 요청용 DTO 구현
주소 등록 및 조회 엔드포인트 구현
주소 페이징 조회 구현
운영환경에서 로깅 메세지 포멧을 지정하도록 모든 범위에서 동일한 로깅 설정 적용
불필요한 정적 팩토리 메서드 제거
결제 UI 호출시 사용자 식별을 위한 customerKey 추가
customerKey 조회 엔드포인트 구현
| private String zipcode; | ||
| private String detailAddress; | ||
|
|
||
| public static Address toEntity(User user, AddressDto dto) { |
There was a problem hiding this comment.
'of' 메서드 이름이 더 낫지 않을까요??
There was a problem hiding this comment.
정적 팩토리 메서드에서 특별한 의미를 가지지 않는 경우 of를 사용하기도 하지만 JPA를 사용하는(또는 그 구현체를 사용하는) 프로젝트에서 데이터들을 통해 Entity를 발급하는 경우 toEntity를 사용하기도 합니다
There was a problem hiding this comment.
그렇군요! Auction.toEntity() 가 다소 어색해서 여쭤봤습니다!
| @@ -0,0 +1,8 @@ | |||
| package org.chzz.market.domain.address.dto.request; | |||
|
|
|||
| public record AddressDto( | |||
There was a problem hiding this comment.
서버에서 해당 값의 유효성 검증은 따로 안하는건가요??
There was a problem hiding this comment.
외부 API를 사용하려고 했는데 유효한 주소인지 검증하기 위해서 도로명 주소지를 검색할 수 있습니다
문제는 해당 API를 사용할때 프론트단에서는 다음 지도 API를 사용해서 검증을 하게 되는데 다음 지도 API가 제가 사용하려는 외부 API와 동일한 도로명 주소를 사용하는지에 대한 확신이 없어 당장에는 별도의 유효성 검증 로직을 따로 작성하지 않았습니다
There was a problem hiding this comment.
근데 도로명 주소지는 전부 동일하지 않나요? 만약한다면 우편번호랑 주소랑 같은지? 확인하면 될것같은데.. 너무 투머치인가싶기도하고 근데 해야될것같긴하고,, 그러네요
There was a problem hiding this comment.
저도 그러길 바랬는데 다음 API 결과를 복사해서 결과가 5개가 나온적이 있습니다
뭐 존재성 여부 검사니까 큰 문제일까 싶기도 하다만은 유일성이 안지켜져서 별도 검증을 적용하지 않았습니다
네 맞습니다 |
화면단 요청시 추가 구현하겠습니다! |
#️⃣연관된 이슈
CHZZ-95
📝작업 내용
✅테스트 결과
🙏리뷰 요구사항(선택)
UUID를 사용해 customerKey를 영속화 전에 발급받는 로직을 구현했습니다
사용자의 경우에는 많은 사용자가 발생하지 않아서 문제가 되지 않겠지만 대형 서비스의 경우에는 분산 서비스에서 UUID의 중복이 발생할 수 있는 문제를 막기 위해 ticket server나 snowflake같은 기술을 사용한다고 알고 있습니다
단일 mysql 서버에 해봐야 3개의 애플리케이션이 물려있어 randomUUID를 사용해도 큰 문제는 없어 보이지만 학습 차원에서 고려해볼만한 요소인거 같습니다
(데이터베이스 uuid 메서드를 사용하는 프로시저를 호출할까도 고민 해봤지만 당장에는 애플리케이션 uuid로 적용했습니다)