2. 요구사항 분석 및 ERD 설계

요구사항 분석

현업에서 개발을 진행할 때 요구사항 분석 과정 없이 바로 개발부터 진행하는 주니어 개발자들이 눈에 많이 보입니다. 개발 이후 막히거나, 기획쪽 수정될 내용을 뒤늦게 찾게되면, 기존 개발했던 로직들을 전반적으로 수정해야해서 개발 시간을 더 달라는 개발자들이 있습니다. 그럴때 저는 반대로 질문합니다.

요구사항 분석 제대로 하셨나요?
개발 전에 충분히 알 수 있었던 내용으로 보입니다만?

 

개발자 중 어떤 개발자는 질적으로도 속도로도 잘하는 개발자가 있는 방면, 어떤개발자는 코드 리뷰에도 수정될 부분이 많이 발생하고 개발시간도 느리게 개발하는 사람들이 있어요. 그런데 그 중 원인을 분석해보면, 요구사항분석을 개발전에 진행했냐? 안했냐로 구분되기도 합니다.

 

요구사항 분석 제대로 하기

 : 무엇을 개발할 지를 여러분들이 가장 잘 이해하기 쉬운언어로 풀어보는 겁니다.

 

이번강의에서의 개발할 내용은?

1) 상품(product)       

     - 사용자가 상품조회(상품정보, 가격정보, 재고수량)

     - 상품 조회만 구성하면 되고, 상품 table 에서 상품정보, 가격정보, 재고수량을 확인할 수 있는 컬럼이 있어야 겠구나!

 

2) 장바구니(cart)

     - 장바구니 조회 

     - 상품을 선택하여 장바구니로 저장

     - 장바구니에서는 상품과, 주문하려는 수량과 가격정보가 있어야 겠구나!

    

3) 주문서(order)

     - 장바구니의 상품을 주문 하기위한 주문서

     - 내가 구매하려는 제품이 주문가능상태(판매중인지? 재고가 있는지?)인가를 검증해야하고 언제 주문했고,

       주문한 수량만큼 재고차감을 해야하겠구나?

       그런데 여러상품을 주문하면?

       여러상품의 총금액을 계산해야 하고,

       상품별 orderDetail table에 저장을 하고 장바구니는 비워줘야 할 것이다.

 

4) 주문서 상세(orderDetail)

     - 주문서에 어떤 상품이 담겼는지 상품 detail 정보

     - 여러개 상품을 주문할 수 있기때문에 body역할인 상세 영역이 필요하구나!

       (주문서가 총 정보가 기입되어있는 Header의 역할이고 주문서 상세는 Body의 역할)

  

/*이외에도 커머스서비스를 운영하기 위해서는 많은 기능이 필요한데 왜 주문 중점적으로 하나요?
라는 질문을 할 수도 있을겁니다. 이러한 구조와 기술을 사용해서 하나를 개발할 수 있으면 다른 영역의 유사한 기능들도 개발이 가능할꺼에요
응용하고 다른기능에 적용하는 몫은 여러분의 몫으로 남겨두겠습니다.*/

 

ERD 설계

 

학습에 필요한 4개의 table 만 사용해보자!

(개발을 배울때에는 단순한 구조가 좋다!)

 

product 는 말그래도 상품정보가 저장되는 곳(옵션정보도 나중에 추가해보자!)

 

order 는 주문정보 저장

하나의 오더번호로 여러 상품을 담을 수 있기때문에 order detail table을 별도로 두었다.

 

끝으로 cart 정보!

왜 오더와 매핑이 없냐!

저 정보는 말그대로 임시 저장소 같은 존재이다.

오더로 넘어가 버리면, 더이상 존재할 필요가 없고, 주기적으로 비워줘야하는 대상이기 때문이다

그럼 왜 cart 는 detail 로 구분하지 않는것인가? 

일반적으로 cart 에 남긴 모든 제품을 주문하기 때문이다.

(파는 사람입장에서도 많이 파는게 이득)

물론, 상황에 따라서는 cart 와 cart detail을 분리해야할 수도 있을 것이다.

 

이후에 Cart table를 사용하지않고 nosql 관점의 redis를 이용하여 리팩토링을 진행할 예정이다.

 

[DB Table 생성]

https://dbdiagram.io/

dbdiagram.io - Database Relationship Diagrams Design Tool

 

※ 위 사이트를 이용해서 ERD를 작성하면, DB 별로 스키마 정보를 자동으로 추출할 수 있다.

 

CREATE TABLE `order` (
  `id` integer PRIMARY KEY AUTOINCREMENT,
  `customer_id` integer,
  `order_no` varchar(255),
  `total_price` integer,
  `status` varchar(255),
  `created_at` timestamp,
  `updated_at` timestamp
);

CREATE TABLE `ordersDetail` (
  `id` integer PRIMARY KEY AUTOINCREMENT,
  `order_no` varchar(255),
  `product_id` integer,
  `unit_price` integer,
  `qty` integer,
  `created_at` timestamp,
  `updated_at` timestamp
);

CREATE TABLE `product` (
  `id` integer PRIMARY KEY AUTOINCREMENT,
  `productname` varchar(255),
  `price` integer,
  `qty` integer
);

CREATE TABLE `cart` (
  `id` integer PRIMARY KEY AUTOINCREMENT,
  `customer_id` integer,
  `product_id` integer,
  `unit_price` integer,
  `qty` integer,
  `created_at` timestamp,
  `updated_at` timestamp
);

 

TypeORM으로 개발 시에는 entity를 먼저 작성하고, DB를 자동생성하는 순이 편할 것이고,

Prisma이용시에는 상기 내역을 이용하여 DB를 먼저 생성시킨 후 pull, generate을 이용하여 prisma schema를 자동생성하는 방식이 편할 것이다.

(FK관계는 삭제하도록 하자)