|
1 | | -# README |
| 1 | +# 📚 Studyroom Service |
| 2 | +> 그룹 기반 스터디룸 예약 관리 백엔드 서비스 |
2 | 3 |
|
3 | | -This README would normally document whatever steps are necessary to get the |
4 | | -application up and running. |
| 4 | +--- |
5 | 5 |
|
6 | | -Things you may want to cover: |
| 6 | +## 1. 프로젝트 개요 |
7 | 7 |
|
8 | | -* Ruby version |
| 8 | +Studyroom Service는 |
| 9 | +**스터디룸을 방 단위로 관리하고, 예약을 안정적으로 처리하기 위한 백엔드 서비스**입니다. |
9 | 10 |
|
10 | | -* System dependencies |
| 11 | +단순 예약 기능을 넘어 |
| 12 | +운영 시간, 휴일, 예약 중복 여부와 같은 조건을 |
| 13 | +**도메인 규칙으로 분리하여 관리**하는 것을 목표로 설계되었습니다. |
11 | 14 |
|
12 | | -* Configuration |
| 15 | +본 서비스는 MSA 구조의 일부로, |
| 16 | +다른 서비스에서 발생한 일정 요청을 받아 |
| 17 | +스터디룸 예약의 정합성을 책임집니다. |
13 | 18 |
|
14 | | -* Database creation |
| 19 | +--- |
15 | 20 |
|
16 | | -* Database initialization |
| 21 | +## 2. 기획 배경 |
17 | 22 |
|
18 | | -* How to run the test suite |
| 23 | +학급 특성상 일본어 특강, 취업 면담 등으로 |
| 24 | +일정 변경이 잦고, 스터디룸이 한정되어 있어 |
| 25 | +예약 충돌이 자주 발생했습니다. |
19 | 26 |
|
20 | | -* Services (job queues, cache servers, search engines, etc.) |
| 27 | +기존에는 |
| 28 | +- 일정 관리 |
| 29 | +- 스터디룸 사용 현황 |
| 30 | +- 개인 일정 |
21 | 31 |
|
22 | | -* Deployment instructions |
| 32 | +이 분리되어 있어 전체 상황을 파악하기 어려웠고, |
| 33 | +이를 통합 관리하기 위한 서비스가 필요하다고 판단해 |
| 34 | +본 서비스를 기획했습니다. |
23 | 35 |
|
24 | | -* ... |
| 36 | +--- |
| 37 | + |
| 38 | +## 3. 서비스 역할 |
| 39 | + |
| 40 | +Studyroom Service는 전체 시스템에서 |
| 41 | +**스터디룸 예약의 최종 책임을 가지는 도메인 서비스**입니다. |
| 42 | + |
| 43 | +- 스터디룸(방) 관리 |
| 44 | +- 방 단위 예약 관리 |
| 45 | +- 예약 가능 여부 검증 |
| 46 | +- 다른 서비스의 예약 요청 처리 |
| 47 | + |
| 48 | +예약에 대한 모든 유효성 판단은 |
| 49 | +본 서비스에서 수행되도록 설계되었습니다. |
| 50 | + |
| 51 | +--- |
| 52 | + |
| 53 | +## 4. 핵심 기능 |
| 54 | + |
| 55 | +### 4.1 스터디룸 관리 |
| 56 | +- 스터디룸 생성 / 수정 / 삭제 |
| 57 | +- 방별 운영 시간 설정 |
| 58 | +- 방별 휴일 설정 |
| 59 | + |
| 60 | +### 4.2 예약 관리 |
| 61 | +- 특정 시간대 예약 생성 |
| 62 | +- 예약 조회 (방 기준 / 전체 기준) |
| 63 | +- 예약 취소 |
| 64 | + |
| 65 | +### 4.3 예약 검증 로직 |
| 66 | +예약 생성 시 다음 조건을 순차적으로 검증합니다. |
| 67 | + |
| 68 | +- 방 존재 여부 |
| 69 | +- 운영 시간 내 요청 여부 |
| 70 | +- 휴일 여부 |
| 71 | +- 기존 예약과의 시간 중복 여부 |
| 72 | + |
| 73 | +이를 통해 잘못된 예약 요청을 사전에 차단합니다. |
| 74 | + |
| 75 | +--- |
| 76 | + |
| 77 | +## 5. 다른 서비스와의 연동 |
| 78 | + |
| 79 | +Studyroom Service는 단독 서비스가 아닌 |
| 80 | +**다른 서비스와의 연동을 전제로 설계**되었습니다. |
| 81 | + |
| 82 | +- Schedule Service에서 일정 생성 시 |
| 83 | + → 스터디룸 예약 요청 가능 |
| 84 | +- 예약 완료 후 |
| 85 | + → 개인 일정, 그룹 일정 등으로 확장 가능 |
| 86 | + |
| 87 | +서비스 간 통신은 **gRPC** 기반으로 구성되었습니다. |
| 88 | + |
| 89 | +--- |
| 90 | + |
| 91 | +## 6. 기술 스택 |
| 92 | + |
| 93 | +- Language: Ruby |
| 94 | +- Framework: Ruby on Rails |
| 95 | +- Communication: gRPC |
| 96 | +- Database: MySQL |
| 97 | +- Infra: Docker, Docker Compose |
| 98 | + |
| 99 | +Rails의 ActiveRecord를 활용해 |
| 100 | +복잡한 SQL 작성 부담을 줄이고, |
| 101 | +비즈니스 로직 구현에 집중할 수 있도록 구성했습니다. |
| 102 | + |
| 103 | +--- |
| 104 | + |
| 105 | +## 7. 설계에서의 고민 |
| 106 | + |
| 107 | +- 예약을 단순 CRUD가 아닌 **도메인 규칙 중심**으로 설계 |
| 108 | +- 예약 가능 여부 판단 책임을 명확히 분리 |
| 109 | +- 다른 서비스가 존재하더라도 |
| 110 | + 예약 정합성은 Studyroom Service에서 보장하도록 설계 |
| 111 | + |
| 112 | +이를 통해 |
| 113 | +**설계가 개발의 방향을 결정한다**는 점을 체감했습니다. |
| 114 | + |
| 115 | +--- |
| 116 | + |
| 117 | +## 8. 향후 개선 계획 |
| 118 | + |
| 119 | +- Kafka 기반 이벤트 연동 |
| 120 | +- 예약 이력 기반 통계 기능 |
| 121 | +- Schedule Service와의 자동 예약 연계 고도화 |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +## 9. Repository |
| 126 | + |
| 127 | +- GitHub |
| 128 | + https://github.com/gsc-lab/cs25-1-bannote-studyroom-service |
0 commit comments