ERD → API → Service 흐름 정리

Controller → Service → Repository → DB 흐름과 구독 도메인 예시 정리

1. 백엔드 계층 흐름 한 장 요약

Client
  ↓ HTTP
Controller (API)
  - Request DTO 파싱
  - 인증 사용자 확인
  - 입력 검증(필수값/형식)
  ↓
Service (Usecase)
  - 비즈니스 정책 실행 (가능/불가 판단)
  - 상태 변경 / 이벤트 발생
  - 트랜잭션 처리
  ↓
Repository
  - 조회/저장 (영속성 처리)
  ↓
DB (ERD)

핵심은 역할 분리다.

• Controller는 HTTP 요청/응답과 입력 검증을 담당한다.
• Service는 비즈니스 정책과 상태 전이를 담당한다.
• Repository는 DB 접근을 담당한다.

---

2. 구독 도메인 ERD 관점에서 API 떠올리기

구독 도메인의 핵심 관계는 다음과 같다.

• 한 사용자는 여러 구독을 가진다.
• 하나의 구독은 하나의 크리에이터에 연결된다.

즉,

users (1) ─── (N) subscriptions ─── (1) creators

Subscription은 단순 연결이 아니라 상태를 가진다.

• status: ACTIVE / PAUSED / CANCELED / EXPIRED 등

상태가 존재하면 정책이 상태 기준으로 동작한다.

---

3. ERD에서 자연스럽게 나오는 API 예시

Subscription을 중심으로 대표 API를 도출하면 다음과 같다.

• POST /subscriptions
  구독 시작
• PATCH /subscriptions/{id}/cancel
  구독 해지(상태 변경)
• GET /users/me/subscriptions
  내 구독 목록 조회
• GET /creators/{id}/contents
  크리에이터 콘텐츠 조회 (구독 여부에 따라 접근 제어 가능)

참고로 구독 해지는 리소스 삭제가 아니라 상태 변경이므로
DELETE보다 PATCH가 더 자연스럽다.

---

4. API 하나를 Service로 내려보내기 

1) POST /subscriptions

Controller는 요청을 받고 인증 사용자와 입력을 확인한다.

• 요청 DTO 파싱
• 로그인 사용자 확인
• creatorId, planId 등 필수값 검증

이후 Service로 위임한다.

예시

SubscriptionService.subscribe(userId, creatorId, planId)

 

 

2) SubscriptionService.subscribe에서 하는 일

Service는 “정책”을 실행한다.

필수 정책 예시

1. 중복 구독 방지
   • 이미 ACTIVE 구독이 있으면 생성 불가
2. 결제 결과에 따른 상태 결정
   • 결제 성공 : ACTIVE
   • 결제 진행 중 : PENDING
   • 결제 실패 : FAILED 또는 PENDING 유지
3. 구독 데이터 저장
   • subscriptions 생성 및 저장
   • started_at, next_billing_at 등 설정
4. 트랜잭션 처리
   • 구독 생성과 결제 상태 반영이 함께 묶여야 한다면 트랜잭션으로 처리

---

5. Repository가 담당하는 범위

Repository는 단순히 DB I/O를 담당한다.

예시 기능

• 현재 구독 조회
  findActiveByUserIdAndCreatorId(userId, creatorId)
• 구독 저장
  save(subscription)

Repository는 정책 판단을 하지 않는다.
정책은 Service에서 한다.

---

최종 정리

Controller → Service → Repository → DB 흐름에서 중요한 것은 각 계층의 책임을 섞지 않는 것이다.

구독 도메인은 users–creators의 N:M 관계를 subscriptions로 풀어내며,
subscriptions는 status를 통해 비즈니스 정책을 수행하는 독립 엔티티가 된다.

ERD에서 관계와 상태를 먼저 잡으면 구독 시작, 해지, 목록 조회 같은 API가 자연스럽게 도출된다.

API는 Controller에서 받고, 정책은 Service에서 실행하며, DB 접근은 Repository로 분리하는 구조가 유지되어야 한다.