[플러스백엔드] 2강 과제 설계

과제 : https://www.notion.so/teamsparta/2-782b11918d194acbba2416a758baf146

 

 

[요구사항 분석]

1. 특강 신청 API 구현

RQ-ID	API	요구사항명	요구사항 내용
RQ-0001	특강신청	선착순 등록	사용자의 userId로 특강신청을 선착순으로 가능.
RQ-0002	특강신청	중복신청 방지	* 특정 신청자가 신청내역에 있는지 확인 * 신청내역에 있다면 중복신청 불가 오류처리
RQ-0003	특강신청	특강 오픈 시간	* 특강은 24년 4월 20일 토요일 1시에 열린다. * 그 시간이 아닐 때는 신청 불가 메시지 출력
RQ-0004	특강신청	최대 신청자 제한	* 최대 30명까지 신청이 가능. * 신청내역에 30건이 되면 그 이후 신청에 대해서는 오류 출력
RQ-0005	특강신청 조회	사용자의 성공여부 조회	* 사용자의 userId로 특강신청내역을 조회하는 기능
RQ-0006	특강신청 조회	전체 신청내역 조회	* 전체 신청내역을 조회하는 기능 => 카운트 가능

 

 

[아키텍쳐 구조]

- 구조 : 레이어드 아키텍쳐 + 클린 아키텍쳐 혼합형태

- Controller <---> Service <---> Repository 구조

- 인터페이스1. 컨트롤러와 서비스 사이에 인터페이스 존재

- 인터페이스2. 서비스와 레포지토리 사이에도 존재해야 하나? DB가 바뀌어도 영향받지 않으려면 인터페이스가 필요하지 않을까??

 

내가 의도한 아키텍쳐

1. 클린 아키텍쳐를 도입 : Controller에서 Service 호출시 인터페이스로 호출한다.

Service 구현 로직은 알 필요 없이 인터페이스로 호출.

2. 공통모듈을 쪼갰다 : Reservation 관련 조회, 쓰기, 검증 등 공통 로직들은 하나의 작은 모듈로 만들어서 책임을 분리하였다.

3. 

 

[데이터베이스]

테이블명 : 강의 예약내역(reservation_list)

컬럼명	컬럼	비고
예약 아이디	id	예약 내역의 고유식별 아이디
사용자 아이디	user_id	특강을 신청한 사용자 아이디
강의 코드	course_code	등록한 특강 코드(상품코드)
강의 시작일자	course_start_date	강의가 시작하는 일자(4월 20일)
예약 일자	reservation_date	특강 예약에 성공한 일자
등록 일시	registered_at	데이터 등록일시
수정 일시	modified_at	데이터 수정일시

 

[DB 설계 고민의 흔적]

1. 예약성공여부를 따로 필드로 만들지 않은 이유는 이미 해당 테이블에 데이터가 있는 것으로 예약이 성공한 것으로 볼 수 있기 때문이다.

2.  요청순번은 요청이 들어올 때마다 아이디를 하나씩 발급해주어야 할까?

그러면 신청내역에 요청순번이 순차적으로 되지 않을 수 있다.(예시 : 1->50->150->200 이런 순서로도 가능)

시퀀셜하게 요청순번을 순차적으로 하려면? 

요청이 먼저 들어와도 등록이 나중에 되는 케이스도 있지 않을까?

3. 강의 코드 : 강의 코드를 추가한 이유는 추후에 특강이 여러개 열릴 수 있어서 확장성을 고려하여 추가

 

 

 

[사용한 기술]

 

 

 

 

 

 

 

기초 과제

- 예약 테이블만 필요

- 예약정보를 넣는 테이블

 

심화 과제

- 날짜를 넣기 위해서는 추가 테이블 추가