오늘은 배달 애플리케이션 프로젝트에서 결제 기능이 실제로 동작할 수 있도록 서비스 계층과 API 컨트롤러를 구현하는 작업을 진행했다.
서비스 계층 구조 설계
먼저 결제 기능의 흐름을 기준으로 서비스 구조를 정리했다. 결제 기능은 크게 결제 승인과 결제 취소 두 가지 유스케이스로 나뉘기 때문에, 이를 각각 ApprovePaymentService와 CancelPaymentService로 분리하여 구현했다.
서비스를 기능별로 분리함으로써 각 서비스가 하나의 역할만 담당하도록 했고, 결제 승인 로직과 결제 취소 로직이 서로 독립적으로 동작하도록 구조를 구성할 수 있었다.
결제 승인 로직 구현
결제 승인 서비스에서는 프론트엔드에서 전달받은 paymentKey, orderId, amount 정보를 기반으로 토스 결제 승인 API를 호출하도록 구현했다.
토스 API 호출이 성공적으로 완료되면 Payment 엔티티의 상태를 APPROVED로 변경하도록 처리했다. 또한 서버에 저장된 결제 금액과 실제 승인 요청 금액이 일치하는지 검증하는 로직을 추가하여 잘못된 결제가 처리되지 않도록 했다.
결제 취소 로직 구현
결제 취소 서비스에서는 먼저 결제 정보를 조회한 뒤, 토스 결제 취소 API를 호출하도록 구현했다.
취소 요청이 정상적으로 처리되면 Payment 엔티티의 상태를 CANCELED로 변경하고 취소 사유를 저장하도록 했다. 이 과정에서 엔티티는 상태 변경만 담당하고, 외부 결제 시스템과의 통신은 서비스 계층에서 처리하도록 역할을 분리했다.
토스 API 연동 구조 구성
외부 결제 시스템인 토스 API와의 연동을 위해 인프라 계층에 TossApprovePayment와 TossCancelPayment 클래스를 구성했다.
서비스 계층에서는 이 클래스들을 통해 토스 API를 호출하도록 하였고, 이를 통해 서비스 계층은 결제 로직에 집중하고 외부 API 호출과 관련된 구현은 인프라 계층에서 관리하도록 구조를 분리했다.
마무리
이번 작업을 통해 결제 기능의 전체 흐름이 Controller → Service → Domain → Infrastructure 구조로 연결되도록 구현할 수 있었다. 또한 도메인은 상태 변경과 비즈니스 규칙에 집중하고, 외부 결제 API 호출은 서비스 계층에서 처리하도록 역할을 분리하면서 각 계층의 책임을 보다 명확하게 이해할 수 있었다.
'TIL' 카테고리의 다른 글
| TIL - GitHub Actions를 이용한 CD 구축 (0) | 2026.03.09 |
|---|---|
| TIL - 결제 로직 변경 (0) | 2026.03.06 |
| TIL - 결제 파트 구조 정리 (0) | 2026.03.04 |
| TIL - 결제 서비스 도메인 설계 및 구현 (0) | 2026.03.03 |
| TIL - Redis TTL 개념정리 (0) | 2026.03.02 |