Skip to content

01-requirements.md

Latest commit

 

History

History
288 lines (219 loc) · 11.1 KB

01-requirements.md

File metadata and controls

288 lines (219 loc) · 11.1 KB

| 요구사항 명세서

1 브랜드 조회

정보 구성

  • 브랜드ID
  • 브랜드명
  • 브랜드 설명
  • 브랜드 상태 : active, inactive
    • active : 정상 서비스 중인 브랜드
    • inactive : 노출하지 않거나 판매 중단된 브랜드
  • 생성일 (최신 판단기준)

기능적 요구사항 ( Functional Requirements )

시스템이 “무엇을” 해야 하는지

Happy Path

  • 브랜드ID를 전달하면 해당 브랜드 정보를 얻는다.

Fail Case

  • 브랜드가 존재하지 않으면 오류를 반환한다.
  • 브랜드 상태가 active 하지 않으면 오류를 반환한다.

비기능적 요구사항 ( Non-Functional Requirements )

시스템이 “어떻게” 해야 하는지 (기능적 요구사항을 제공하기 위한 방법)

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다. 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다**.**

    상황 HTTP 상태코드 설명
    브랜드 없음 404 Not Found brandId로 조회했을 때 없을 때
    브랜드 상태가 active가 아닐 때 404 Not Found

2 상품 조회

정보 구성

  • 상품 목록/상세 공통 정보
    • 상품ID
    • 브랜드명
    • 상품명
    • 가격
    • 좋아요 수
    • 등록일(최신 판단)
  • 상품 상세 추가 정보
    • 상품 상세 설명
    • 상품 상태 표시
      • 상품 상태 : 판매중, 일시 품절, 판매 중지
  • 상품 상태
    • 판매중
    • 판매중단
    • 일시품절 : 상품이 판매(결제)될 때, 재고가 0이면 상품의 상태를 일시품절로 처리한다.

기능적 요구사항 ( Functional Requirements )

Happy Path

  • 상품 목록 조회의 경우,
    • 해당 브랜드ID의 상품 목록을 페이징 형태로 상품 목록을 반환한다.
      • 정렬 조건이 없으면, 최신 등록 상품 순으로 가져온다.
    • 브랜드ID가 없으면, 정렬 조건으로 페이징 형태로 상품 목록을 반환한다.
      • 정렬 조건이 없으면, 최신 등록 상품 순으로 가져온다.
    • 페이징에는 정렬 조건이 있다.
      • 정렬 조건
        • 필수: 페이지 정보
          • 페이지 정보가 있다는 것은 조건들이 DB쿼리에 명시되어 있어야 한다는 것.
          • 즉, 도메인에서 메서드로 validate하는 것이 의미가 없다.
        • 기본 최신순, 좋아요 수, 가격
  • 상품 상세 조회의 경우, 해당 상품ID의 상품 상세를 반환한다.

Fail Case

  • 상품이 존재하지 않으면 오류를 반환한다.
  • 해당 브랜드 상태가 active가 아니면 오류를 반환한다.
  • 상품 상태가 조건에 만족하지 않으면 오류를 반환한다.
    • 상품 목록 : 판매중 상태만 노출
    • 상품 상세 : 판매중, 일시 품절, 판매 중지 상태 표시

비기능적 요구사항 ( Non-Functional Requirements )

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다.

    상황 HTTP 상태코드 설명
    상품 없음 404 Not Found productId로 조회했을 때 없을 때
    브랜드 상태가 active가 아닐 때 404 Not Found
    상품 상태가 조건에 만족하지 않을 때 404 Not Found

3 좋아요

정보 구성

  • 상품 목록과 동일한 정보 구성

  • 좋아요ID

  • 상품ID

  • 상품명

  • 가격

  • 상품 상태

  • 브랜드명

기능적 요구사항 ( Functional Requirements )

Happy Path

  • 좋아요는 상품 목록, 상품 상세에서 가능하다.
  • 사용자는 로그인한 상태에서 좋아요 기능이 가능하다.
  • “판매중, 일시 품절” 상태의 상품에 좋아요가 가능하다.
  • 좋아요 목록 조회 시에 “판매중, 일시 품절” 상태의 상품이 조회된다.

Fail Case

  • 로그인하지 않은 사용자에게는 오류를 반환한다.
  • 상품이 존재하지 않으면 오류를 반환한다.
  • 상품이 “판매중, 일시 품절 상태”가 아니라면 오류를 반환한다.
  • 좋아요 등록/해제가 실패하면 오류를 반환한다.

비기능적 요구사항 ( Non-Functional Requirements )

  • 사용자 인증은 X-USER-ID Header 기반으로 처리한다.

  • 좋아요 등록/해제는 멱등성을 보장한다.

    • 이미 좋아요 한 상품에 좋아요 등록 요청해도 오류가 아닌 OK 응답.
    • 좋아요 기록이 없는 상품에 좋아요 해제 요청해도 오류가 아닌 OK응답.

  • 좋아요 수는 집계되어 실시간 또는 준실시간으로 제공한다.

    • 좋아요 등록/해제 시 좋아요 수 +/- 업데이트

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다

    상황 HTTP 상태코드 설명
    미로그인 401 Unauthorized 헤더가 없거나 유효하지 않을 때
    상품 없음 404 Not Found productId로 조회했을 때 없을 때
    이미 좋아요한 상품에 다시 좋아요 요청 200 OK 멱등성 유지
    좋아요하지 않은 상품에 해제 요청 200 OK 멱등성 유지
    상품 상태 조건 미달 400 Bad Request “판매중, 일시 품절 상태” 아닐 때

4 주문 요청

정보 구성

  • 주문ID
  • 사용자ID
  • 주문 아이템 목록
    • 상품ID
    • 상품 금액(스냅샷)
    • 상품 주문 수량
  • 주문 총액 : 주문 아이템에 대한 총 금액
  • 결제 금액 : 결제가 필요한 금액
  • 주문 상태 (상태 예: PENDING → PAID → FAILED)
    • 주문 상태는 결제가 분리되었기 때문에 필요하다.
    • PENDING : 주문서를 저장할 때
    • FAIL_VALIDATION: 유효성 실패할 때
    • PAID : 결제 요청이 성공할 때
    • FAILED : 결제 요청이 실패할 때
  • 주문 일시 : 주문 생성 시점
    • 주문 생성 시점
      • 주문서 페이지에서 “결제하기” 버튼을 눌렀을 때이다.
    • 주문서 생성에 대한 멱등성 고려
      • 주문 요청 시, header에 X-ORDER-REQUEST-ID를 전달한다.
        • 클라이언트의 멱등키 생성 제약사항: UUID로 생성한다.
      • X-ORDER-REQUEST-ID가 같을 경우, 200 OK 반환
      • 응답 바디에 해당 주문 정보 및 중복 요청값(duplicateRequest: true/false)을 전달한다.
  • 수정 일시 : 주문 상태가 변경될 때 함께 변경된다.

기능적 요구사항 ( Functional Requirements )

Happy Path

  1. 사용자는 로그인한 상태에서 주문이 가능하다.
  2. 주문요청번호(멱등키)당 주문은 하나만 생성이 가능하다.
  3. 상품번호가 유효한 상품에 대해 주문이 가능하다.
  4. 주문 총액만큼 포인트를 보유해야 한다.

Fail Case

  • 로그인하지 않은 사용자에게는 오류를 반환한다.
  • 존재하지 않는 상품이면 오류를 반환한다.
  • 보유 포인트가 부족하면 오류를 반환한다.
  • 주문 요청이 실패하면 오류를 반환한다.
  • 멱등성 보장 : 주문서 화면에서 여러 번 요청할 경우, 한 번만 처리한다.

비기능적 요구사항 ( Non-Functional Requirements )

  • 사용자 인증은 X-USER-ID Header 기반으로 처리한다.

  • 주문 등록의 멱등성 보장 방법은 아래와 같이 처리한다.

    • 주문 요청 시, X-ORDER-REQUEST-ID Header를 주문과 함께 요청한다.
    • 주문 생성 시, OrderRequestId와 함께 주문 상태를 PENDING으로 저장한다.
    • 멱등성을 보장하기 위해 OrderRequestId에 DB의 고유(UNIQUE) 제약 조건을 적용한다.
      • 해당 id로 주문 요청을 보냈을 때 Unique제약 조건 오류가 발생하면, 해당 주문 정보와 200 OK를 응답한다.
    • OrderRequestId 는 UUID로 생성한다.

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다.

    상황 HTTP 상태코드 설명
    미로그인 401 Unauthorized 헤더가 없거나 유효하지 않을 때
    상품 없음 404 Not Found productId로 조회했을 때 없을 때
    보유 포인트 부족 409 Conflict
    여러 번 주문 요청을 한 경우 200 OK 같은 OrderRequestId로 여러 번 요청

5 결제

정보 구성

  • 결제 ID
  • 주문ID
  • 결제 금액
  • 결제 일시

기능적 요구사항 ( Functional Requirements )

Happy Path

  1. 사용자는 로그인한 상태에서 결제가 가능하다.
  2. 결제는 따로 사용자가 요청하지 않고, 주문 요청 시 결제 요청이 내부적으로 발생한다.
  3. 재고가 있는 상품에 결제가 가능하다.
  4. 주문 총액만큼 포인트를 보유해야 한다.

Fail Case

  • 로그인하지 않은 사용자에게는 오류를 반환한다.
  • 상품 재고가 없는 경우 오류를 반환한다.
  • 보유 포인트가 부족하면 오류를 반환한다.
  • 결제 요청이 실패하면 오류를 반환한다.

비기능적 요구사항 ( Non-Functional Requirements )

  • 사용자 인증은 X-USER-ID Header 기반으로 처리한다.

  • 재고가 없는 경우, 주문 상태를 Failed 로 변경하고 409 Conflict 응답을 보낸다.

  • 상품이 판매(결제)될 때, 재고가 0이면 상품의 상태를 일시품절로 처리한다.

  • 보유 포인트가 부족한 경우, 주문 상태를 Failed 로 변경하고 409 Conflict 응답을 보낸다.

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다.

    상황 HTTP 상태코드 설명
    미로그인 401 Unauthorized 헤더가 없거나 유효하지 않을 때
    상품 재고 없음 409 Conflict
    보유 포인트 부족 409 Conflict

6 주문 조회

정보 구성

  • 상품 목록/상세 공통 정보
    • 주문ID
    • 사용자ID
    • 주문 총액
    • 주문 상태 (상태: PENDING,PAID,FAILED)
    • 주문 일시
    • 수정 일시
  • 상품 상세 추가 정보
    • 주문 아이템 목록
      • 상품ID
      • 상품 금액(스냅샷)
      • 상품 주문 수량

기능적 요구사항 ( Functional Requirements )

Happy Path

  • 사용자는 로그인한 상태에서 주문 조회가 가능하다.
  • 본인의 주문에만 접근 가능하다.

Fail Case

  • 로그인하지 않은 사용자에게는 오류를 반환한다.
  • 본인의 주문이 아닌 경우에는 오류를 반환한다.

비기능적 요구사항 ( Non-Functional Requirements )

  • 사용자 인증은 X-USER-ID Header 기반으로 처리한다.

  • 오류 상황에서는 명확한 HTTP 상태코드와 에러메세지를 반환해야 한다.

    상황 HTTP 상태코드 설명
    미로그인 401 Unauthorized 헤더가 없거나 유효하지 않을 때
    본인의 주문이 아닌 경우 403 Forbidden