🚀 데브코스 1차 프로젝트 시작
벌써 데브코스를 시작한 지 한 달이 지났다.
이론 위주의 학습을 지나, 드디어 첫 팀 프로젝트를 진행하게 됐다.
이번 1차 프로젝트는
- 일주일 동안
- 4명이 한 팀이 되어
- 역할을 분담해 하나의 서비스를 완성하는 방식으로 진행된다.
기본적인 템플릿은 제공되었고,
그 위에 팀 회의를 통해 구조와 구현 방향을 정해 프로젝트를 진행했다.
Spring으로 CRUD를 직접 구현해보는 첫 팀 프로젝트라 기대도 되고, 살짝 긴장도 되는 순간이었다.
☕ 1차 프로젝트 개요
카페 메뉴 관리 서비스
첫 번째 프로젝트의 주제는 카페 메뉴 관리 서비스다.
Spring Framework를 사용해
카페의 커피 메뉴 데이터를 관리하는
CRUD(Create, Read, Update, Delete) 기능을 구현하는 것이 핵심 목표다.
단순히 기능 구현에 그치지 않고,
HTTP 메서드 설계, 데이터베이스 연동, 팀 단위 협업까지
백엔드 개발의 기본 흐름을 경험하는 데 목적이 있다.
📅 프로젝트 일정 및 팀 구성
| 구분 | 내용 |
|---|---|
| 프로젝트 기간 | 12/15 (월) 09:00 ~ 12/22 (월) 18:00 |
| 프로젝트 발표 | 12/22 (월) |
| 팀 구성 | 총 4명, 1차 프로젝트 팀으로 진행 |
짧은 기간이지만,
그만큼 빠르게 설계하고 구현하며 집중도가 필요한 프로젝트다.
🎯 기술 요구 사항 요약
CRUD 기능 구현
- Create
POST메서드 사용- 요청마다 id가 1씩 증가하며 DB에 저장
- Read
GET메서드 사용
- Update
PUT메서드 사용- 특정 id의 데이터 수정
- Delete
DELETE메서드 사용- 특정 id의 데이터 삭제
데이터베이스 연동
- SQL 또는 ORM 중 하나 선택
- 직접 설계한 데이터베이스를 프로젝트에 연동
🏪 프로젝트 배경 (시나리오)
우리는 작은 로컬 카페 ‘Grids & Circles’라는 설정이다.
- 고객은 온라인 웹사이트를 통해 커피 원두 패키지를 주문한다.
- 주문은 전날 오후 2시부터 당일 오후 2시까지 모아서 처리한다.
- 하루 동안 들어온 주문은 다음 날 한 번에 배송된다.
- 현재 판매 중인 상품은 총 4개다.
고객 관리 방식
- 별도의 회원가입은 없다.
- 주문 시 입력한 이메일 주소로 고객을 구분한다.
- 하루에 여러 번 주문해도 하나의 주문으로 합쳐 처리한다.
💡
고객에게는
“당일 오후 2시 이후 주문 건은 다음 날 배송이 시작됩니다.”
라고 안내한다.
👥 역할 분담
이번 프로젝트는 총 4명이 각 도메인을 맡아 병렬로 개발을 진행했다.
각자 맡은 역할과 책임은 아래와 같다.
🛒 상품 관리 — 팀장님
상품 도메인은 카페에서 판매하는 상품 정보를 관리하는 영역이다.
주요 기능
- 상품 정보 관리
- 상품 정보: 사진, 이름, 가격, 분야
- 어드민 권한
- 상품 추가 / 삭제 / 수정
- 사용자 권한
- 전체 상품 조회 가능
- (기능 확장) 상품 검색
- (상품 수 증가 시) 페이징 처리
- 상품 이미지 처리
- 이미지 저장 방식: MySQL 저장 / URL 저장 방식 중 선택
- 프로젝트 규모와 이미지 수를 고려해 MySQL에 저장하는 방식 채택
API
GET /product : 상품 리스트 조회
GET /product/{id} : 특정 상품 조회
POST /product : 상품 생성
PUT /product?id= : 상품 정보 수정
DELETE /product?id= : 상품 삭제
📦 주문 관리 — ME
주문 도메인은 사용자의 주문 생성부터 상태 관리까지를 담당한다.
주요 기능
- 주문 생성, 조회, 상태 변경
- 같은 이메일 + 같은 배송일 주문은 하나로 병합
- 주문 시간 기준
- 전날 14시 ~ 당일 14시 주문을 하나의 배송 단위로 처리
- 데이터 정리
- 이틀 전 주문 데이터 삭제
- 주문 완료 상태 데이터 삭제
- 스케줄러를 활용해 자동 처리
API
POST /orders : 주문 생성 (시간 기준 주문 병합)
GET /orders/{orderId} : 주문 단건 조회
PATCH /orders/{orderId}/status : 주문 상태 변경
이틀 전 데이터 및 주문 완료 건 삭제는 스케줄러로 처리
🛠 어드민 관리 — 팀원
어드민 도메인은 주문 전체를 관리하고, 예외 케이스를 처리하는 영역이다.
주요 기능
- 어드민 주문 리스트 조회
- 전날 14시 ~ 당일 14시 기준 주문 데이터 반환
- 필요 시 페이징 적용
- 주문 처리
- 처리 완료 주문 삭제 또는 상태 변경
- 예외 주문 처리
- 데이터가 비정상적인 주문에 대해
- 삭제 또는 사용자에게 안내
- 데이터가 비정상적인 주문에 대해
API
(미정) POST /admin : 어드민 생성
(미정) GET /admins : 어드민 조회
GET /admin/lists : 주문 리스트 조회
(미정) GET /admin/list/{id} : 주문 단건 조회
(미정) PUT /admin/list/{id} : 주문 처리
DELETE /admin/list/{id} : 주문 삭제
(미정) GET /admin/lists/{userId} : userId 기반 주문 리스트 조회
👤 유저 관리 — 팀원
유저 도메인은 회원가입 없는 구조에서 고객 정보를 관리하는 역할을 맡는다.
주요 기능
- 주문 시 입력한 이메일 기준으로 고객 구분
- 주문 발생 시 이메일 기반 유저 자동 생성
- 어드민 전용 기능
- 유저 전체 조회 / 단건 조회
- 유저 정보 수정 / 삭제
API
POST /users : 유저 생성
GET /users : 유저 전체 조회
GET /users/{userId} : 유저 단건 조회
PUT /users/{userId} : 유저 수정
DELETE /users/{userId} : 유저 삭제
🗓️ 1일차 — 내가 한 일
✨ 구현 기능 명세
- 주문 엔티티 생성
- 주문 상태
enum정의 - JPA 어노테이션 매핑
- 주문 도메인 기본 구조 설계
✅ PR Point
entity/Order- 주문 엔티티 생성
entity/OrderStatus- 주문 상태
enum분리 및 정의
- 주문 상태
- 주문 관련 패키지 구조 정리
controllerservicerepositorydto
- 각 파일별 기본 코드 구조 작성
orders폴더 위치 변경 및 도메인 구조 정리
😭 어려웠던 점
- 주문 상태를
enum으로 분리하는 방식이
과연 현재 프로젝트 규모에 적절한 설계인지 확신이 들지 않았다. - 뭔가 수업내용을 실제로 적용하려고 하니 또 다른거 같아서 어렵다.
