권상현 | 김석재 | 류성훈 | 정미정 |
---|---|---|---|
Github | Github | Github | Github |
💻 Team work | 📒 Project page |
공지사항, 컨벤션 공유 등 우리 팀을 위한 룰 |
요구사항 분석, 정보 공유 및 원할한 프로젝트를 위해 사용 |
- 주어진 데이터를 여러 필터링을 사용하여 레스토랑의 인사이트를 보여주는 API를 만든다
누가 사용 할 서비스인가?
-
크게 세가지 권한 단위로 구분 할 수 있다
- 서비스 전체를 관리, 프랜차이즈들을 관리하고 정보를 조회 하는
API 서비스 관리자
- 서비스 관리자는 고객은 아니지만 관리를 위해 서비스를 사용하게 될 것이다
- 해당 프랜차이즈의 음식점과 메뉴(menu)를 관리하고 정보를 조회하는
프랜차이즈 관리자
- 지점들의 정보를 분석해 프랜차이즈가 이윤을 추구 하는 전략, 방침을 제시할 수 있다
- 해당 음식점의 정보를 조회하는
음식점 점주
- 해당 지점의 상권 특성을 분석해 같은 프랜차이즈 내에서도 차별화를 둘 수 있다
- 서비스 전체를 관리, 프랜차이즈들을 관리하고 정보를 조회 하는
어떤 관계로 이루어져 있는가?
-
프랜차이즈(Subsidary)
는id와 이름으로 구분
되며음식 지점
들을 가지고있고 그 지점에서 판매하는메뉴
를 가지고있다. 나중에는 지점별로 특성에 맞게 변형 될 수 있겠지만 메뉴의 기본 틀은 프랜차이즈를 따라간다 -
음식점(Restaurant)
의 이름(Name)은 프랜차이즈와 주소(Ward) (예시: 버거킹, 서초구 신림동)로 이루어져있으며 같은 주소에 같은 프랜차이즈가 있을 경우를 대비해호점(Store)
이라는 숫자로 구분 할 수 있다 -
메뉴(Menu)
는 소속된 프랜차이즈 , 이름 과 가격 으로 이루어져있다 -
음식점에서 나오는
결과(Result)
는 한 테이블의 주문 정보 라고 볼 수 있다 음식점 , 프랜차이즈 , 결제수단(Payment) , 인원수(number_of_party) , 총금액(total_payment) 로 이루어져있다. -
결과만 봐서는 총 금액은 알 수 있지만 어떤 메뉴를 주문했는지 알 수 가 없어 결과와 메뉴를 Many to many 로 연결해주는
메뉴결과(ResultMenu)
는 주문 이라고 볼 수 있다. -
메뉴결과(ResultMenu)
는 어떤 메뉴인지 , 어느 테이블(결과) 인지 양(quantity) 은 얼마나 되는지 표시 할 수 있다.
할인(discount_rate)
을 주문에서 적용 할 수 있게 해 같은 메뉴 몇개 이상시 할인 혹은 직원 할인, 프랜차이즈 프로모션 , 지점에 맞춘 특별 할인등에 유연하게 적용 할 수있다.
어떤 정보를 조회(집계) 할 수 있는가?
- 먼저 필수로
기간
과시간단위(time_window)
이 필요하다 그리고 크게 세가지를 기준으로 집계를 할 수 있다.금액 범위
결제 수단
인원 수
- RDB 사용 - MySQL
- Django
- REST API V1 구현
- POS의 결제 정보를 RDB로 보냅니다
- 레스토랑 KPI를 집계
- REST API V2 구현
- Unit test codes
- REST API Documentation (Swagger UI)
REST API V1
-
필수
-
생성
레스토랑 정보 Restaurant 주문총계 (총 결제금액, 인원수 등) Result 주문결과 (주문 내역) ResultMenu 업종 정보 Subsidary - POS의 결제 정보를 RDB로 보냅니다
-
어떤 method를 사용할 것인가?
-
업로드 해야하는 데이터
→ number of a party (인원 수)
→ how much they pay (결제 금액)
→ restaurant id (레스토랑 id → RDS에서 자동적으로 만들어지는 id)
→ timestamp
-
- POS의 결제 정보를 RDB로 보냅니다
-
조회
-
레스토랑별 KPI
관리자는 다양한 필터를 이용해 집계를 확인할 수 있습니다.
-
집계 기능
-
시간단위
→ e.g. HOUR, DAY, WEEK, MONTH, YEAR
-
-
필터 기능
-
input
-
기간 별 (must)
→ e.g. Start: 2022-04-14 00:01:31 in KT / End: 2022-04-16 00:12:34 in KT
-
금액 별 (optional)
→ e.g., from 20000 won to 100000 won
-
인원 별 (optional)
→ e.g., from 2 to 2
-
레스토랑 별 (optional)
→ e.g., 비비고 (1), 빕스버거 (2)
-
-
output
-
필요한 파라미터
- 기간 : start_date , end_date
- 금액 : start_price, end_price
- 인원 : start_ , end_
- 레스토랑별 :
- 어떻게 정렬 할 것인지 : 합, 평균, 최대값 등
-
-
-
-
-
선택
- REST API document - Swagger
- Test cases code
REST API V2
-
생성
- 메뉴 생성 Menu
-
조회
-
(선택) 수정
- 가게정보 Restaurant
- 메뉴 Menu
- 업종 정보 Subsidary
-
(선택) 삭제
- 가게 정보 Restaurant
- 업종 정보 Subsidary
- 메뉴 Menu
- 결과 Result
- 주문 취소 ResultMenu
-
D 팀 추가 option
- 메뉴 할인
- 메뉴 토핑 (or 곱빼기)
- 관리자 테이블 ( 인증 )
- Restaurant 테이블을 하나의 객체(점주)로 지정해도 무방할 듯.
- ID, Password, 점주 이름 컬럼만 추가
- 업종 (Subsidary) CRUD 기능
- 레스토랑 (Restaurant) CRUD 기능
- 메뉴 (Menu) CRUD 기능
- 주문 (Result) Create 기능
- 조건 별 KPI R(조회)
- Test cases code - Restaurant, Menu, Subsidary
- API 명세서 - SWAGGER
- 메뉴 할인
- 메뉴 토핑
- 관리자 기능
docker를 이용해 프로젝트 api를 컨테이너화 하여 EC2에 배포했습니다
AWS 요금 문제로 배포가 중지 될 수 있습니다
AWS 요금 문제로 배포가 중지 될 수 있습니다
Pytest-Django로 구현 된 24개의 테스트 구현, 통과 완료