💡 아래 명세를 잘 읽어보고, 서버를 구현합니다.
Description
- 특강 신청 서비스를 구현해 봅니다.
- 항해 플러스 토요일 특강을 신청할 수 있는 서비스를 개발합니다.
- 특강 신청 및 신청자 목록 관리를 RDBMS를 이용해 관리할 방법을 고민합니다.
Requirements
- 아래 2가지 API 를 구현합니다.
- 특강 신청 API
- 특강 신청 여부 조회 API
- 각 기능 및 제약 사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.
- 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.
- 동시성 이슈를 고려하여 구현합니다.
API Specs
1️⃣ (핵심) 특강 신청 API POST /lectures/apply
- 특정 userId 로 선착순으로 제공되는 특강을 신청하는 API 를 작성합니다.
- 동일한 신청자는 한 번의 수강 신청만 성공할 수 있습니다.
- 각 강의는 선착순 30명만 신청 가능합니다.
- 이미 신청자가 30명이 초과되면 이후 신청자는 요청을 실패합니다.
- 어떤 유저가 특강을 신청했는지 히스토리를 저장해야한다.
2️⃣ (기본) 특강 목록 API GET /lectures
- 단 한번의 특강을 위한 것이 아닌 날짜별로 특강이 존재할 수 있는 범용적인 서비스로 변화시켜 봅니다.
- 이를 수용하기 위해, 특강 엔티티의 경우 기본 과제 SPEC 을 만족하는 설계에서 변경되어야 할 수 있습니다.
- 수강신청 API 요청 및 응답 또한 이를 잘 수용할 수 있는 구조로 변경되어야 할 것입니다.
- 특강의 정원은 30명으로 고정이며, 사용자는 각 특강에 신청하기전 목록을 조회해볼 수 있어야 합니다.
- 추가로 정원이 특강마다 다르다면 어떻게 처리할것인가..? 고민해 보셔라~
3️⃣ (기본) 특강 신청 완료 여부 조회 API GET /lectures/application/{userId}
- 특정 userId 로 특강 신청 완료 여부를 조회하는 API 를 작성합니다.
- 특강 신청에 성공한 사용자는 성공했음을, 특강 등록자 명단에 없는 사용자는 실패했음을 반환합니다. (true, false)
💡 KEY POINT
- 정확하게 30명의 사용자에게만 특강을 제공할 방법을 고민해 봅니다.
- 같은 사용자에게 여러 번의 특강 슬롯이 제공되지 않도록 제한할 방법을 고민해 봅니다.
천방지축 어리둥절 빙글빙글 돌아가는 1주였다.
지난주보다는 시간분배도 잘했다고 생각했는데,
ERD 설계(랄 것도 사실 없지만...)부터 구현 및 테스트까지,
시간이 모자랐다.
하현우 코치님이 입이 닳도록 프로젝트 구조에 대해 설명하시는 거 들어서 구조 잘 짤 수 있다고 생각했는데,
컨트롤러 테스트 해서 컨트롤러 만드는 것까진 신나게 했는데,
Entity와 DTO를 나누고, 레파지토리를 추상화하는 과정에서 멘붕이 왔다.
DTO를 Entity로 바꾸어서 전달하고, 디비에서 받은 데이터를 다시 Entity에서 DTO로 바꿔서 던져주고 해야 한다고 머리는 이해하는데...
어느 위치에서 어떤 시점에 해야하는 거지...?
멘붕에 빠져서 시간을 엄청 잡아 먹었다.
레파지토리 추상화도 그냥 repository랑 impl로 나누면 되겠지 하고 있었는데,
JPA 레파지토리 추상화를 검색해 보니 갑자기 레파지토리커스텀이 등장하는 게 아닌가.
그래그래, 쿼리 커스텀해서 쓰니까 레파지토리커스텀을 써야하는구나.
근데 이건 또 어느 위치에서 어디에 참조해야하는 거지?
진짜 이 부분에서 모든 시간을 다 써버렸다.
그래서 선착순 30명 조건을 충족하기 위해 비관적 락을 적용하고 동시성 테스트 하는 코드는 날림으로 작성했다.
사실 동시성 테스트는 실패해서 다시 손봐야한다ㅠ
그래도 어찌어찌 2주 간의 챕터 1의 끝났다.
코드 실력은 상승했다고 보기 어렵겠지만 관념적인 시야는 조금 성장한 것 같다.
레이어드 아키텍처 기반의 클린 아키텍처는 어떻게 해야 하는가에 대해 조금은 익숙해졌고,
코드를 짤 때 이 기술을 왜 여기서 써야 하는지에 대해 생각하려 연습하고 있다.
챕터 2를 하는 3주 간의 목표는 클린 아키텍처에 익숙해지는 것 + 객체지향적인 코드를 짜는 것이다.
(절차지향적인 코드라고 피드백 받아서 슬프다)
그리고 아고라나 DM을 적어도 한 번은 사용해보는 것이 목표다.
내 지식이 많이 부족하다고 느껴 오히려 아고라나 DM으로 코치님께 물어보기가 어렵다.
Keep : 모르는 부분은 팀원들과 공유해서 해결하는 부분
Problem : 내가 모르는 것에 대해 말로 정리하기가 어렵다
Try : 아고라랑 DM도 활용해보자!