🍀e-commerce 요구사항 분석

---

우리가 가장 대표적인 e-commerce를 만든다고 가정해보자.

당연히 떠오르는게 많을 것이다.

1. 뭐 고객은 상품 주문이 가능하고...
2. 판매자는 상품을 등록할 수 있고...
3. 장바구니도 있어야 할테고...
4. 한번에 여러가지 주문이 가능해야 할테고...

여기서 드는 의문이 있다.
이걸 이렇게 대충 생각해서 프로젝트를 시작해도 될까...?
과연 뛰어난 개발자들이 이걸 대충 생각할까 ?
아니다. 사실 이 단계를 대충하면 확장성과 유지 보수를 고려한 설계가 나오기가 힘들다.

예시를 들어보자.
고객은 상품 주문이 가능하다.
라는 사실에서 우리가 요구사항 분석을 끝내면 어떻게 될까 ?

아마 개발자는 고객 테이블을 만들고, 상품 테이블을 만들고, 고객과 상품 테이블을 연결하는 일대다 다대일 주문 테이블을 만들것이다...

ㄴ 이렇게 하면 당연히 망한다...

고객은 상품 주문이 가능하다. 라는 사실만으로는 부족하다.

고객이 있다.
상품이 있다.
고객은 장바구니를 하나씩 갖는다.
고객은 다른 상품을 여러개 동시에 묶어서 주문이 가능하다.
동시에 여러개 묶어서 주문하는 경우는 장바구니에 여러 상품이 담겨있고, 장바구니를 통해서 주문하는 경우이다.
개별 주문은 두가지 경우로 해석할 수 있다.
1. 장바구니를 통해서 = 장바구니에 하나의 상품만을 담아서 주문한다.
2. 장바구니를 통하지 않고 = 장바구니를 애초에 거치치 있고 바로 개별 상품 구매시 바로 주문서로 넘어간다.
두가지 케이스에 따라서 설계가 달라진다. -> 뭐가 더 효율적일까 ?

최소한 이 정도의 생각은 하고 개발을 진행해야 한다.
이러면 얘기가 달라진다.

이러면 개발자가 할일은

1. 고객 테이블 만들기
2. 상품 테이블 만들기
3. 고객 한명단 일대일로 장바구니 테이블을 만들고
4. 장바구니와 상품의 다대다 매핑할 수 있는 장바구니-상품 테이블을 만들고
5. 주문 테이블을 만들고
6. 주문과 상품의 다대다 매핑을 위한 중간 테이블을 만들고
7. 무조건 장바구니를 통해서 주문을 할지 말지를 결정한다.

사실 위의 1~6번은 쉽지만, 가장 어려운건 7번이다.
무엇이 효율적일까 ? 늘 고민해야 한다.

어쨋든 위의 과정을 요구사항 분석이라고 부른다.

사실 제대로 문서를 다 만들면서 요구사항 분석을 하기에는 시간적 무리가 있으니
최소한의 스텝으로 분석해보자.

---

액터

e-commerce에는 어떤 액터가 있을까 ?
그리고 액터의 액티비티에는 어떤게 있을까 ?

액터는 흔히 서비스를 이용하는 주체라고 생각하면 된다.

주체라는 말이 모호한데, 사람일수도 있고 다른 외부 서비스일 수도 있다.
여기서는 사람이라는 가정을 하고 넘어가겠다.

대강 e-commerce에

1. 고객
2. 판매자
3. 배송업체
4. 서비스 운영진

이렇게 네명의 액터가 있다고 가정해보자.

이때 대부분의 서비스는 각각의 하부 서비스를 이용하게 된다.

1. 고객은 Front server + api server 가 합쳐진 서비스를 사용하게 되고,
2. 판매자는 판매자 전용의 어드민을 사용하게 된다.
3. 배송업체는 배송업체 전용의 어드민을 사용하게 된다.
4. 운영진은 운영진 전용의 어드민을 사용하게 된다.

물론 전부 다 구현하는게 맞지만, 2~4번의 어드민을 하나의 어드민에 몰아넣어서 어드민을 만들 예정이다.
예를 들어서 운영진이 직접 판매자와 배송업체에게 컨택하고 등록하는 서비스라고 가정하는 것이다.
그러면 판매자와 배송업체의 정보를 운영진이 직접 등록하게 된다.
ㄴ 사실 어드민 3개 만들기 귀찮아서 그런다.

이랬을때, 4명의 액터가 서비스를 이용하는게 아니다. 사실상 두명(고객, 운영진)이 사용하는 서비스가 된다.

두명의 액터가 사용할 수 있는 전체 기능에 대해서 생각해보자.

---

유스케이스

유스 케이스는 액터의 액티비티라고 보면 된다.
여기서 어떤 기능이 있으면 될지 생각해보자.

일단 생각나는대로 적어보자.

* 유스케이스를 자세하게 하는 건 시간이 오래 걸려서 기능 위주로 하겠습니다 !

고객 입장

1. 고객은 회원가입과 로그인이 가능하다.
2. 고객은 자신의 주소와 개인정보를 등록할 수 있다.
3. 고객은 하나씩의 장바구니를 갖는다.
4. 고객은 원하는 상품을 원하는 수량으로 장바구니에 담을 수 있다.
5. 이때 주문은 장바구니 단위로 할수도 있고, 개별 주문도 가능하다.
6. 이때 개별 주문도 장바구니에 담아서 한다.
7. 자신이 주문한 상품들과 배송 현황을 확인 할 수 있다.

운영진 입장

1. 판매자, 회원, 상품, 배송 업체, 카테고리의 CRUD가 가능해야 한다.
2. 상품과 카테고리를 연결할 수 있어야 한다.
3. 해당 상품을 배송할 배송 업체를 고를 수 있어야 한다.
4. 판매자, 회원, 상품, 배송 업체, 주문, 카테고리의 통계성 조회가 가능해야 한다.

여기서 통계성 조회라는 건 예를 들어서 이런거다.
특정 상품이 특정 기간동안 어떤 회원들에게 판매됬는지, 얼마나 많이 판매됬는지, 이 상품의 정산 비율을 몇인지, 등등
상품과 관련된 모든 정보를 볼 수 있는 페이지를 의미한다.

---

어드민 요구사항

판매자 어드민과 배송업체 어드민을 생략한다고 했지만,

그래도 당연히판매자가 자신가 어떤 상품을 올렸는지 얼마나 많이 주문이 됬는지를 파악하려면 당연히 판매자 어드민은 있어야 한다. 하지만 그건 운영진 어드민의 일부 기능(조회, 통계)만을 갖고 있는 어드민이 되기 때문에, 직접 구현하지는 않을 예정이다.

운영진 어드민에는 어떤 기능들이 필요할까 ?
크게 나눠보면,
1. 데이터를 CRUD 할 수 있는 기능
2. 단순 조회가 아닌 정산, 통계성 조회 기능

이 기능들을 좀 더 세분화시켜보자.

조회 기능

1. 어떤 판매자들이 있는지 확인할 수 있어야 한다.
2. 어떤 회원이 있는지 확인할 수 있어야 한다.
3. 어떤 배송업체들이 있는지 확인할 수 있어야 한다.
4. 어떤 상품이 있는지 확인할 수 있어야 한다.
5. 어떤 카테고리가 있는지 확인할 수 있어야 한다.
6. 주문 현황을 파악할 수 있어야 한다.

등록 기능

1. 판매자를 등록할 수 있어야 한다.
2. 상품과 상품의 정보들을 등록할 수 있어야 한다.
3. 배송 업체를 등록할 수 있어야 한다.
4. 카테고리를 등록할 수 있어야 한다.

수정 기능

1. 판매자의 정보를 수정할 수 있어야 한다.
2. 상품의 정보를 수정할 수 있어야 한다.
3. 배송 업체의 정보를 수정할 수 있어야 한다.
4. 카테고리를 수정할 수 있어야 한다.

삭제 기능

1. 판매자를 삭제할 수 있어야 한다.
2. 상품을 삭제할 수 있어야 한다.
3. 배송 업체를 삭제할 수 있어야 한다.
4. 카테고리를 삭제할 수 있어야 한다.

기타 요구사항

1. 회원, 판매자, 배송업체, 주문, 카테고리의 통계를 확인할 수 있어야 한다. (날짜별 주문 데이터, 회원 가입 수, 등등)
2. 운영진과 판매자의 정산 비율을 정하면, 최종 정산액을 확인할 수 있어야 한다.

---

일단은 이정도로 정리해보겠다.
실제 e-commerce admin에는 더더더더 많은 기능들이 필요하겠지만,

내가 생각했을때, 정말 최소한의 어드민 기능은 이정도인것 같다 !

앞으로 직접 구현하면서 더 필요한 기능들이 있으면 그때 그때 추가할 예정이다.