RockPay

RockPay는 Kotlin과 Spring Boot 기반의 이커머스 결제 정산 플랫폼입니다.

프로젝트 구조

멀티모듈 아키텍처

RockPay
├── apis/                   # API 레이어 (포트: 8081)
│   ├── api-order          # 주문 REST API
│   ├── api-core           # 코어 REST API
│   └── api-docs           # API 문서
│
├── applications/          # 애플리케이션 레이어
│   ├── app-order          # 주문 비즈니스 로직 및 유스케이스
│   └── app-core           # 코어 비즈니스 로직
│
├── domain/                # 도메인 레이어
│   ├── domain-order       # 주문 도메인 (Order, OrderItem, Delivery)
│   ├── domain-core        # 코어 도메인
│   └── domain-support     # 도메인 공통 유틸리티 (Price 등)
│
├── infrastructure/        # 인프라 레이어
│   ├── databases/
│   │   ├── db-order      # 주문 데이터베이스 설정
│   │   └── db-core       # 코어 데이터베이스 설정
│   └── messaging/         # Kafka/RabbitMQ 설정
│
└── clients/               # 외부 통신 레이어
    ├── client-product    # 상품 서비스 통신 (OpenFeign)
    └── client-example    # 예제 클라이언트

레이어별 역할

API Layer

• REST API 엔드포인트 제공
• 요청/응답 처리 및 검증
• api-core: 주문을 제외한 API (포트 8080)
• api-order: 주문 관련 API (포트 8081)

Application Layer

• 비즈니스 로직 오케스트레이션
• 유스케이스 구현
• 이벤트 발행 (예: OrderCreationEventPublisher)
• 도메인과 인프라스트럭처 연결

Domain Layer

• 순수 비즈니스 로직
• 엔티티, 값 객체, 도메인 이벤트
• 리포지토리 인터페이스 정의
• 인프라스트럭처 의존성 없음

Infrastructure Layer

• 데이터베이스 설정 (H2/MySQL 멀티 프로파일)
• 메시지 브로커 설정 (Kafka/RabbitMQ)
• 도메인 인터페이스 구현

Clients Layer

• 외부 서비스 통신
• OpenFeign을 사용한 서비스 간 통신
• API 응답 모델 관리

의존성 흐름

API → Application → Domain
      ↓              ↓
   Infrastructure ← Domain

• API 모듈은 Application에 의존
• Application은 Domain과 Infrastructure에 의존
• Domain은 어떤 레이어에도 의존하지 않음
• Infrastructure는 Domain 인터페이스를 구현
• Clients는 어떤 레이어에도 의존하지 않음

기술 스택

• Language: Kotlin 1.9.25
• Framework: Spring Boot 3.5.3, Spring Cloud 2025.0.0
• Database: H2 (local), MySQL (local-dev)
• Messaging: Kafka, RabbitMQ
• Test: Kotest, SpringMockK, ArchUnit
• Communication: OpenFeign

주요 설정

데이터베이스 프로파일

• local/default: H2 인메모리 DB (DDL auto-create)
• local-dev: MySQL on localhost:13306

메시징 설정

• Kafka 기본 포트: 9092
• RabbitMQ 기본 포트: 5672
• 설정 기반 브로커 타입 선택 가능

---

요구사항

1. 판매자 관련

• 판매자는 상품 판매를 목적으로 가입을 할 수 있다.
• 판매자는 퇴점을 이유로 탈퇴를 할 수 있다.
• 판매자는 상품 판매를 목적으로 상품을 등록할 수 있다.
• 판매자는 상품 정보 변경을 목적으로 상품을 수정할 수 있다.
• 판매자는 재고 관리 목적으로 상품의 재고를 수정할 수 있다.
• 판매자는 배송 관리 목적으로 주문 상태(배송 준비/배송 중/배송 완료)를 변경할 수 있다.
• 판매자는 매출 확인을 목적으로 주문 및 정산 내역을 조회할 수 있다.
• 판매자는 정확한 지급을 목적으로 정산 계좌 정보를 등록·수정할 수 있다.
• 판매자는 정산 주기 관리를 목적으로 정산 주기를 선택할 수 있다.

---

2. 구매자

• 구매자는 상품 구매를 목적으로 결제를 할 수 있다.
• 구매자는 상품 교환/환불을 목적으로 반품을 요청할 수 있다.
• 구매자는 배송 추적을 목적으로 주문 배송 상태를 확인할 수 있다.
• 구매자는 가격 혜택을 목적으로 쿠폰을 사용할 수 있다.
• 구매자는 적립 혜택을 목적으로 포인트를 사용할 수 있다.
• 구매자는 추가 혜택을 목적으로 상품 할인 적용을 받을 수 있다.

---

3. 관리자 관련

• 관리자는 정산 정확성을 목적으로 판매자별 거래 내역을 집계할 수 있다.
• 관리자는 투명성을 보장하기 위해 토스페이먼츠 결제/환불 내역과 대조할 수 있다.
• 관리자는 정산 리스크 관리 목적으로 특정 판매자의 정산을 보류할 수 있다.
• 관리자는 정산 이슈 해결 목적으로 보류 상태를 해제할 수 있다.
• 관리자는 지급 안정성을 목적으로 송금 실패 내역을 재처리할 수 있다.

---

4. 정산 시스템

• 시스템은 결제 발생 시점에 거래 원장에 기록할 수 있다.
• 시스템은 환불 발생 시 원장에 차감 건을 기록할 수 있다.
• 시스템은 배송 완료 여부를 매출 확정 조건으로 반영할 수 있다.
• 시스템은 정산 주기에 따라 판매자별 지급 예정 금액을 산출할 수 있다.
• 시스템은 쿠폰/할인/포인트 내역을 반영하여 정산 금액을 정확하게 계산할 수 있다.
• 시스템은 수수료 체계를 반영하기 위해 판매 수수료, PG 수수료, VAT를 구분 계산할 수 있다.
• 시스템은 송금 처리를 목적으로 토스페이먼츠 API를 호출할 수 있다.
• 시스템은 송금 오류 발생 시 해당 정산 건을 보류 상태로 전환할 수 있다.
• 시스템은 보류 해소 시점에 정산 금액을 합산 지급할 수 있다.
• 시스템은 예상 정산액을 판매자에게 노출하기 위해 정산 대기 금액을 계산할 수 있다.
• 시스템은 투명성을 보장하기 위해 정산 결과를 판매자에게 알림할 수 있다.
• 시스템은 정산 내역의 이력을 관리하기 위해 원장을 수정 불가능한 로그로 보관할 수 있다.
• 시스템은 세무 신고를 지원하기 위해 정산 데이터를 부가세/원천징수 기준으로 분리할 수 있다.
• 시스템은 연체/차감 처리를 위해 마이너스 정산 건을 관리할 수 있다.
• 시스템은 정산 리스크 방지를 위해 이상 거래(과도한 환불, 비정상 패턴)를 탐지할 수 있다.
• 시스템은 플랫폼 수익 관리를 위해 플랫폼 부담 할인액과 판매자 부담 할인액을 구분 반영할 수 있다.
• 시스템은 포인트 적립/사용 내역을 반영하기 위해 포인트 비용을 정산 로직에 포함할 수 있다.
• 시스템은 정산 마감 후 정산 리포트를 자동으로 생성할 수 있다.
• 시스템은 회계 일관성을 위해 정산 데이터 전체를 아카이브할 수 있다.