Intro
Spring Boot 3.4.0 Java 21 MySQL 8 JPA
  • 우리는 PG사 API와 연동하여 결제 서비스를 클라이언트에게 제공해주고 있다.
  • 결제 서비스 내에서도 결제 수단 등록/삭제, 결제 수단 조회와 등록된 결제 수단을 통한 책정 금액 결제 또는 책정 금액의 청구서를 카카오톡으로 발송
  1. 우리는 가맹점과 소비자의 중간 매개체 역할이며, 소비자가 이용한 서비스에 대한 책정 금액을 가맹점이 결정하여 우리에게 전달한다.
  2. 우리는 책정된 금액과 소비자 정보를 전달받아 결제 방식을 결정한다.
    1. 만약 소비자가 우리의 플랫폼 APP의 회원일 경우, PG사에서 제공해주는 자동 결제 시스템을 통해 소비자가 미리 등록한 결제 수단으로 즉시 결제 요청한다.
    2. 소비자가 미리 등록한 결제 수단이 없거나 결제 수단에 문제가 있다고 판단될 경우, 소비자의 연락처를 통해 카카오톡 청구서를 발송한다.
    3. 소비자가 우리의 플랫폼 APP의 회원이 아닐 경우, 즉시 카카오톡 청구서 방식으로 요청한다.
  3. 결제 요청 후, PG사로부터 Callback API를 통해 결제 요청 결과를 수신 받는다.
  4. 환불이 필요할 경우, 결제 요청 당시 생성한 청구서 ID와 요청 금액을 전달하여 환불 요청한다.
  5. 재결제가 필요할 경우, 환불 요청 후, 새로운 청구서 ID를 생성하여 결제 요청한다.
  • 기존 결제 서비스는 모든 외부 모듈들이 필수로 주입 받고 있는 common 모듈 안에 구현되어있어서 결제 서비스가 필요하지 않더라도 인스턴스를 생성하고 있었다.
  • 우리는 기존 서비스 기능에 대한 고도화 작업 및 신규 기능 추가 작업으로 인해 점차 리소스 비용이 증가하고 있었다.
  • 따라서 결제 서비스 전용 모듈을 분리하여 MSA 아키텍처로 전환하기로 결정하였다.
  • 이를 통해 결제 서비스의 독립성을 확보하고, 서비스 간의 의존성을 줄이며, 향후 기능 확장 및 유지보수를 용이하게 할 수 있을 것으로 기대하고 있다.
  • 또한, MSA 아키텍처로의 전환은 각 서비스의 배포 및 확장을 독립적으로 수행할 수 있는 기반을 마련해줄 것이다.

목표

  • 결제 서비스의 독립성을 확보하고, 서비스 간의 의존성을 줄인다.
  • 향후 기능 확장 및 유지보수를 용이하게 한다.
  • 각 서비스의 배포 및 확장을 독립적으로 수행할 수 있는 기반을 마련한다.
  • 추상화 구조로 설계해본다. 어댑터 패턴 (Adapter Pattern) 이란?
  • 기존 복잡한 VIEW TABLE을 사용하지 않는 방향으로, 제거하는 방향으로 설계해보자.
  • 결제 모듈만이 관리하는 테이블과 각 클라이언트가 관리하는 테이블을 분리하고 각자 관리한다.