서비스 개요
서비스 목적 및 목표
목적
숙박업소를 조회하고 예약하는 서비스를 만든다.
목표
- REST API를 구현하여 FE에게 JSON 형식의 데이터를 전달합니다.
- 회원 인증과 인가를 Spring Security를 이용하여 진행합니다.
- 숙박 상품에 대한 데이터를 오픈 API를 통해 검증/활용합니다.
- 전체 상품 조회 시 한 페이지에 출력되는 상품 개수에 따라 DB Paging을 수행합니다.
- DB 트랜잭션과 동시성 제어를 고려합니다.
서비스 설계
패키지 구조
✅ DDD 설계
- 각각의 도메인 별로 패키지 분리가 가능하여 도메인 별 관리가 직관적입니다.
- 도메인 별로 의존하는 코드가 없도록 설계가 되었기 때문에 추후에 기획이 추가되더라도 코드를 재활용할 수 있기에 domain형 구조를 선택했습니다.
요구사항 분석
이번 미니 프로젝트는 구체적인 요구사항들이 많아, 팀원들과 먼저 요구사항을 꼼꼼히 분석하고 넘어갔다.
Event Storming
요구사항 분석을 토대로 사용자 flow를 이해하기 위해 event storming을 진행했다.
사용자가 어떤 행동을 할지 작성해보면서, 이에 따른 예외처리들을 미리 결정하고 개발을 시작할 수 있어서 개발 시간을 단축할 수 있었다.
ERD
Architecture
서비스 기능
개발스택
- java 17
- springboot 3.1.5
- spring data jpa (+ QueryDSL)
- spring web
- Spring Security
- Spring Batch (For OpenApi Crawler)
- DataBase
- mysql 8.0
- h2 (For Test)
- redis
- Infrastructure
- AWS EC2, RDS
- Nginx
- CI/CD
- Github Action
- AWS Code Deploy
입출력화면 & 배포
🔗 배포 사이트 : https://candid-horse-912de6.netlify.app/
(⚠️ 현재 서버 다운으로 배포 사이트 진입 불가)
so2zy 프로젝트에서는 Spring REST Docs를 도입하여 API를 문서화했다.
입출력화면은 다음과 같은 링크를 통해 확인할 수 있다.
🔗 So2zy Spring REST Docs : https://api.so2zy.com/docs/index.html
내가 맡았던 숙소상세조회 API와 장바구니 객실 추가 API RestDocs는 다음과 같다.
역할 분담
⚡ 팀원들의 이름은 비공개처리했다.
내가 맡은 업무는 총 2가지였다.
숙소(객실) 상세 조회
장바구니 추가- 장바구니 api - Create 추가 #1 : https://for-if.tistory.com/72
- 장바구니 api - Create 추가 #2 : https://for-if.tistory.com/73
팀 협업
플래닝 포커(Planning Poker)을 통해 백로그의 구현 난이도를 측정하였고 적절하게 태스크를 분배했습니다.
당장 급하지 않은 기능은 2차로 뺏습니다.
스프린트 도중 백로그는 언제든지 추가될 수 있습니다.
각 스프린트의 마지막 날에는 스프린트 리뷰 테스트(실제 애플리케이션 구동 테스트)를 진행합니다.
1차 스프린트 (11.21 ~ 11.24)
🔗 1차 스프린트 : https://github.com/orgs/so2zy/projects/2/views/1
🔗 1.0 Release Note : https://github.com/so2zy/so2zy_BE/wiki/So2zy-1.0-Release-Notes
2차 스프린트 (11.26 ~ 11.30)
🔗 2차 스프린트 : https://github.com/orgs/so2zy/projects/4
🔗 2.0 Release Note : https://github.com/so2zy/so2zy_BE/wiki/So2zy-2.0-Release-Notes
- 찜된 숙소 보여주기
- 날짜별로 남은 재고 보여주기
- 인원 체크해서 maxCapacity >= 인원 인 방만 보여주기
- startDate~endDate 날짜 계산해서 가격 곱해주기
- 숙소 이미지도 list가 아닌 url로 보여주기
- uri 변경 (PathVariable → RequestParam)
- “로그인 시 장바구니 생성 → 장바구니에 객실 추가시, 장바구니 생성” 으로 변경
- 객실상품(roomProduct)테이블 생성으로 모든 코드 변경
- 남은 객실의 수보다 더 추가를 누르면 exception 추가
리팩토링
🔗 Refactoring : https://github.com/so2zy/so2zy_BE_refactor
- Github Action을 통한
CI 전략을 추가하여 안정적으로 PR을 진행했다.
- AWS의 Code Deploy를 활용하여 CD전략을 추가했고,
무중단 배포를 구현했다.
Trouble Shooting 🚀
⚡구체적인 Trouble Shooting은 자체 포스팅에 구체적으로 작성해뒀다.
⚠️ stackOverFlow Error : https://for-if.tistory.com/66
⚠️ Jackson 직렬화 제한자 문제 : https://for-if.tistory.com/67
⚠️ UnsupportedTemporalTypeException HH:MM : https://for-if.tistory.com/68
⚠️ MultiBagFetchException : https://for-if.tistory.com/69
⚠️ UnsupportedOperationException : https://for-if.tistory.com/70
⚠️ query did not return a unique result : https://for-if.tistory.com/71
프로젝트를 마무리하며 .. 🐣
2주동안 FE개발자들과 함께 웹 프로젝트를 진행하면서 협업에 대해 많이 배울 수 있었다.
- BE개발자가 API를 개발할 때, request와 response data type을 미리 notion으로 문서화해드리면, FE개발자가 이를 토대로 MSW를 사용하여 개발을 진행할 수 있다는 점을 배울 수 있었다.
- data type의 변경은, FE개발자의 수정이 필요하므로 최대한 꼼꼼한 기획을 통해 수정하는 일을 줄여함을 깨닫게 됐다.
- Response를 모두 작성해주어 모든 예외처리에 대해 FE개발자들이 인지할 수 있도록 해야한다.
- 이를 위해, notion api 문서화를 최대한 꼼꼼히하려 노력했다. 특히, Success인 상황과 Fail인 상황을 모두 작성해두고 API의 로직을 구체적으로 설명해두어 혼동되는 부분이 없도록 체크했다.
Uploaded by N2T