[과제] 결제 시스템 Day6

https://github.com/teeeam3/payment-assignment

GitHub - teeeam3/payment-assignment: 결제 도메인 프로젝트입니다

 

TIL: 결제 보상 트랜잭션 및 포인트 연동 트러블슈팅
1. Trouble (문제 상황)
메서드 불일치: PaymentService에서 호출하는 포인트 적립 메서드명(accumulate)이  PointService의 명세(registPoint)와 달라 컴파일 에러 발생.

보상 트랜잭션 누락: 결제 실패 시 적립된 포인트를 취소하는 로직만 있고, 사용자가 결제 시 사용했던 포인트를 돌려주는 로직이 설계에서 누락됨.

엔티티 생성 제약: Payment.create() 메서드에 사용 포인트(usedPoint) 필드가 없어, 결제 취소 시 복구해야 할 포인트 금액을 추적할 수 없는 구조적 문제 발견.

2. Shoot (해결 방법)
서비스 레이어 동기화: PointService의 실제 메서드명인 registPoint와 cancelPoint로 호출부를 수정하여 지혁 님 코드와의 의존성 문제 해결.

엔티티 고도화: Payment 엔티티에 usedPoint 필드를 추가하고, 정적 팩토리 메서드(create)에서 생성 시점에 포인트를 기록하도록 수정.

복구 로직 분리: 결제 실패(catch 블록) 시 order를 재조회하여 적립 취소(cancelPoint)와 사용 취소(복구) 로직을 순차적으로 배치해 데이터 무결성 확보.

검증 로직 완화: 전액 포인트 결제 시 결제 금액이 0원이 될 수 있음을 고려하여, 금액 검증 조건을 0보다 커야 함에서 0보다 크거나 같아야 함으로 유연하게 수정.

3. Learned (배운 점)
협업의 기술: 내가 짠 로직이 아무리 완벽해도 동료가 짠 서비스(PointService)의 명세와 다르면 무용지물이며, 적극적인 코드 싱크가 개발 속도를 높인다는 것을 깨달음.

역추적성(Traceability): 결제 취소와 같은 사후 처리를 위해서는 결제 생성 시점부터 필요한 모든 정보(사용 포인트 등)를 스냅샷처럼 엔티티에 남겨야 함을 확인.

방어적 프로그래밍: 예외 상황(결제 실패)을 단순한 에러로 치부하지 않고, 포인트와 재고를 원상복구하는 '보상 트랜잭션' 설계가 이커머스 개발의 핵심임을 알게되었다!