[Point-live-young (1)] 포인트 기반 결제 도메인 설계

https://github.com/f-lab-edu/point-live-young

GitHub - f-lab-edu/point-live-young: 대규모 사용자와 대용량 트래픽을 안정적으로 처리하는 포인트 기반

 

 

Point Live Young 프로젝트를 시작하면서 가장 먼저 고민한 것은 
"이 서비스에서 포인트를 단순한 숫자로 볼수 있는가?" 였다.

 

대부분의 프로젝트에서는 포인트를 int 또는 long 값 하나로 관리한다.

사용자가 보유한 포인트 총합만 알면 되고,

결제 시에는 그 값에서 차감하면 끝이기 때문이다.

 

하지만 이 프로젝트는 처음부터 그 방식이 맞지 않았다.

---

왜 ‘포인트 기반 결제’였을까?

Point Live Young은 현금 결제가 없는 이커머스를 목표로 한다.

모든 상품은 오직 포인트로만 구매할 수 있고,

포인트는 다양한 정책을 통해 지급된다.

• 회원가입 포인트
• 출석 포인트
• 생일 포인트
• 이벤트 포인트

 

여기서 중요한 점은 단순히 "포인트가 있다"가 아니라

👉 각 포인트는 성격이 다르고, 생명주기가 다르다는 것이다.

---

포인트는 더 이상 '숫자'가 아니다.

어떤 포인트는 영구적으로 사용할 수 있고,

어떤 포인트는 유효기간이 존재한다.

 

그리고 정책에 따라

 

• 사용 가능한 상품이 다를 수도 있고
• 사용 우선순위가 달라질 수도 있다.

 

이 순간부터 포인트는 더 이상

“사용자가 가진 하나의 숫자” 로 다룰 수 없는 개념이 되었다.

---

포인트를 하나의 '자산 도메인'으로 바라보다.

 

그래서 포인트를 이렇게 정의했다.

포인트는 정책에 의해 생성되고,
시간에 따라 소멸될 수 있는 자산이다.

 

이 관점으로 바꾸자 도메인이 완전히 달라졌다.

• 포인트는 언제, 어떤 이유로 지급되었는지 추적되어야 한다.
• 만료일이 존재한다면, 사용 순서에 대한 규칙이 필요하다.
• 단순 합산이 아니라 구성 요소들의 집합으로 관리되어야 한다.

 

결과적으로 포인트를 하나의 값이 아닌

여러 개의 포인트 묶음(Lot) 으로 관리하는 구조를 선택했다.

---

포인트 도메인 모델링 방향

핵심은 “포인트의 생성 단위와 사용 단위를 분리”하는 것이었다.

 

• 사용자는 여러 개의 포인트 묶음을 가진다.
• 각 묶음은 다음 정보를 가진다.
  • 어떤 정책으로 지급되었는지
  • 지급 시점
  • 만료 시점
  • 남은 포인트

 

이 구조 덕분에 이후 요구사항이 자연스럽게 풀리기 시작했다.

 

예를 들어,

• 만료가 임박한 포인트부터 사용해야 한다
• 특정 정책 포인트는 일부 상품에만 사용 가능하다
• 이벤트 포인트만 따로 통계로 보고 싶다

 

같은 요구사항이 도메인 레벨에서 자연스럽게 표현될 수 있었다.

---

“나중에 필요할 수도”를 지금 설계에 반영한 이유

 

이 프로젝트는 개인 포트폴리오 프로젝트지만,

실무와 최대한 가까운 문제를 다루고 싶었다.

 

실제 서비스에서는 다음과 같은 요구가

언젠가는 반드시 등장한다고 생각했다.

 

• 포인트 만료 정책 변경
• 신규 포인트 정책 추가
• 포인트 사용 이력 감사
• 포인트 관련 CS 대응

 

초기에는 과한 설계처럼 보일 수 있지만,

포인트를 자산으로 모델링한 덕분에

이 요구사항들은 “기능 추가” 수준으로 해결 가능해졌다.

---

정리하며

 

이 글에서 말하고 싶었던 핵심은 단 하나다.

포인트는 숫자가 아니라 도메인이다.
그리고 이 프로젝트는 그 관점에서부터 시작되었다.

 

Point Live Young 프로젝트의 시작은

기술 스택이 아니라 이 관점의 전환에서 출발했다.

 

다음 글에서는

이 도메인 설계 위에서

“포인트를 어떤 순서로 차감할 것인가?”,

즉 만료 우선 차감(Early Expiry First) 알고리즘을

어떻게 고민하고 구현했는지 정리해보려고 한다.