[쇼핑몰 프로젝트] 요구사항 정리

대원·2024년 5월 16일

쇼핑몰

목록 보기

1/13

요구사항 정리

기능요구사항 분석

상품관리 - 판매자 권한

상품 생성(판매자 생성)
- 상품을 생성할 수 있다.
  - 상품에 맞는 속성들을 productRequestDTO의 형식을 아래 속성들을 지닌채로 POST 요청을 서버에 보낸다.
  - 상품의 생성은 '관리자'만 가능하다.
상품 이미지 등록
- 상품의 이미지를 등록할 수 있다.
  - 이미지 등록은 Optional하다고 가정해보자. ( Null 허용)
  - product_image
  - 이미지의 상대적으로 데이터 크기가 큰데 Data Type은 무엇으로?
    - 서버의 부담은 없을까?
  - Img_url을 S3에 저장(경로)
    - 왜 RDS, S3를 분산했을까?
  - img_data는 어떻게 어디에 저장하고 또 Data Type은 보통 무엇으로 하지?

~~상품 색상 등록~~
- ~~상품의 색상을 등록 /변경할 수 있다.~~
  - ~~product_color~~
  - ~~Not Null이라고 가정한다.~~
    - ~~Q) 색상의 의미가 잘 와닿지 않는다.~~
상품 카테고리 구분(등록)
- 상품의 카테고리를 구분할 수 있다.
  - null / category
    - Q) Category가 null값을 허용하면 구분한다고 할 수 있을까?
  - category와 상품은 1: n관계(하나의 카테고리가 여러 개의 상품을 가질 수 있다. )
  - 일단은 상품은 여러 개의 카테고리를 가질 수 없다고 가정한다.
상품 가격 등록
- 상품은 가격을 등록할 수 있다.
- 애초에 상품을 생성할때 가격을 결정해야 한다.
- 상품은 가격을 가지고 있다. (가격은 필수값이라고 가정한다 .Not Null)

관리자를 사전에 인증하게끔 하는 방법은 무엇이 있을까?

-> 상품의 생성은 관리자만 가능. 
서버에 HTTP 요청을 보내는 상황 전에 관리자 인증이 되어있어야 한다.(관리자 로그인)

서버에서 관리자임을 또 한 번 인증하는 것이 의미가 있을까? 또 해주는게 좋을까? 

(일단은 여기는 고려하지 않는다. )

상품 조회

전체 상품리스트 조회
- List 형태로 반환한다.
- 전체 상품을 조회한다.
- 일단은 Paging을 고려 안 한다.

상품주문

상품 주문
- 상품을 주문할 수 있다.

장바구니 관리

장바구니 관리(제품, 수량)
- 상품의 수량(개수)를 선택해서 장바구니에 넣을 수 있다.
- 장바구니에는 여러 개의 상품이 존재할 수 있고 상품은 여러 개의 수량을 가질 수 있다.
장바구니에서 주문하기
- 하나의 장바구니는 하나의 사용자가 있다.
- 사용자는 주문할 수 있다.

채팅관리

1:1 채팅 문의 기능

도메인 도출 및 Entity 도출

도메인(비즈니스가 해결하고자 하는 문제영역) / 각 Entity가 갖고있어야할 Attribute 정의

상품(product)
- Product_id(상품 번호) / long형
- name / String형
- price (상품 가격) / int형
- category_id / long형
  - Category Entity의 pk인 category_id와 mapping
  - 다대일
- Image_url / string형
  - 이미지를 저장할 경로
주문
- order_id(주문번호) / long형
- List - 주문상세(OrderDetail) Entity 필요?

주문 상세
- id
- name
- price
- cnt
장바구니
- cart_id /long형
- name / String형
카테고리(?)
- category_id / long형
- name / String형
- Q) 카테고리는 도메인이 되고 상품의 여러 속성들(가령 금액 등)은 도메인으로 정의하지 않는 이유는?
  - A) '상품은 카테고리를 구분할 수 있어야 한다.'라는 요구사항과 같이, 비즈니스가 해결하고자 하는 대상의 범위에 속하기 때문에?
채팅
사용자(생략되었지만 유추한 도메인)
- 상품을 주문하거나, 상품을 조회하는 주체 -> 사용자

생성시간, 수정시간은 BaseEntity라는 Entity를 생성해서 위의 Entity가 상속하여 작성한다.

도메인 간 관계 정의

도메인 간 관계를 정의하는 중간에 Entity가 도출되나?

도메인이 보통 Entity로 구성이 되지만, 추가 Entity가 필요할 수도 있는 것처럼 보인다.

상품
- 하나의 상품은 여러 명의 사용자를 가질 수 있다.
- 한 명의 사용자는 여러 상품을 가질 수 있다.
- 상품과 사용자는 N:N 역할을 한다.
- 상품과 사용자의 중간테이블로 주문 테이블이 있다.
주문
- 상품과 사용자의 매개역할
- 하나의 주문은 여러 개의 '주문 상세(세부내역)'가 있다.
- ex)
  A 아이템 3개, B item 2개 -> 주문(주문이 '개수'를 가지고 있을 필요가 있을까?)
  A 아이템을 3개 주문 -> 주문 상세
카테고리
- 하나의 카테고리는 여러 개의 상품을 갖는다 (1: N)
1:1 채팅
- 유저는 1:1 채팅을 통해 문의 할 수 있다.
- 누구와 채팅을 하는가?
- 판매자(상품을 생성한)
- 채팅은 여러 명의 사용자를 갖는다.
  채팅은 여러 명의 판매자를 갖는다.
- 한 명의 여러 명의 판매자를 갖는다.(?)
- 한 명의 판매자는 여러 명의 사용자를 갖는다.(?)
- Q) 구매자와 판매자는 사용자라는 하나의 테이블에서 User_Role을 통해 구분하면 안되지 않을까?
  채팅을 구현하기 위해서는 사용자가 사용자의 채팅을 매개로 연결되야하는데, 판매자와 사용자가 하나의 테이블로 관리된다면, 구현이 가능할까? 또 그것이 적합한 방식일까?
장바구니
- 한 명의 사용자는 하나의 장바구니를 지닌다. (1:1 관계)
- 장바구니에서 주문을 할 수 있다.
- 하나의 장바구니는 하나의 사용자를 갖고, 하나의 사용자는 여러 개의 주문을 갖는다.
  (1: 1 : N)

API 설계

기능	URL	HTTP METHOD
상품을 생성한다.	api/product	POST
상품 리스트를 조회한다.	api/products	GET
상품을 주문한다.	api/order	POST
장바구니에 상품을 추가한다.	api/cart/product	POST
장바구니에서 상품을 주문한다.	api/cart/order	POST