TroubleShooting
25.04.15 결제 도메인에서 마일리지/쿠폰 차감 책임을 분리한 이유
ddong-kka
2025. 4. 15. 13:13
문제 : 결제 서비스가 모든 걸 다 처리한다.
현제 payment 서비스는 결제 요청을 받으면 이런 작업을 과정을 수행하고있다.
- 마일리지 쿠폰, 사용 여부 판단
- 사용 요청 이벤트 발행
- 결제 엔티티 생성 및 저장
- 차감 결과에 따라 결제 성공/ 실패 처리
처음에 이게 맞나? 싶었는데 시간이 지나면서 문제들을 느끼게되었다.
도메인 책임이 어긋나 있다
결제 해택 차감까지 담당한다.
결제 도메인이 쿠폰과 마일리지를 검증하고, 실패 여부에 따라 결제 자체를 실패 처리하고 있었다. 이는 단일 책임 원칙(SRP)을 심각하게 위반한 구조라고 생각이 들었다.
이벤트 흐름이 꼬인다.
원래라면 혜택을 차감하고 결제 요청을 보내는 게 자연스러운 순서다. 그런데 실제로는 결제 요청 → 혜택 차감 요청 순으로 처리되면서, 차감이 실패하면 결제를 취소하는 순서가되는게 부자연스럽게 느껴졌다.
결론 : 예매(Booking) 도메인에서 차감, 결제 도메인은 결제만 진행하는게 맞다.
개선 전의 이벤트 흐름은 이렇다.
개선전의 흐름
booing -> payment -> auth -> payment ( 차감 결과를 반환 )
개선 후 흐름
Booking -> auth -> Booking -> payment
- 예매 도메인에서 마일리지 / 쿠폰 검증 및 차감을 먼저 수행한다.
- 마일리지 및 쿠폰 사용이 없으면 그대로 결제 요청을 보낸다.
- 차감이 완료되면, 최종 결제 금액을 포함한 결제 요청을 보낸다.
- 결제 도메인은 해당 금액으로 결제만 처리한다.
이슈 해결 후 얻은 효과
| 항목 | 효과 |
| 단일 책임 원칙 (SRP) | 각 도메인이 본인의 역할에만 집중하게 되어 유지보수가 쉬워짐 |
| 이벤트 흐름 정리 | 이벤트의 순서가 자연스럽고 예측 가능하게 정리됨 |
| 도메인 간 의존성 감소 | 결제 도메인이 혜택 도메인에 의존하지 않게 됨 |
| 예외 처리 단순화 | 감 실패는 예매 도메인에서만 처리하면 되어 복잡성 감소 |
최종 결과
이번 이슈를 통해 도메인의 경계를 명확히 하고, 이벤트 흐름을 다시 고민해볼 수 있었다.
처음부터 찝찝했는데 해결 할 수 있어서 속이 시원하다. 마음이 급해서 내가 설계를 잘못해버린 잘못이다..
사소한 문제였지만 개발이 진행되면서 실제 운영을 생각하면 짚고 넘어가야할 부분이라 발표 이틀 전에 수정 작업을 진행하게되었다. 역시 찝찝할 때 바로 알아보고 변경하는게 최고다.