서비스 개요
서비스 목적 및 목표
목적
여행 여정을 기록과 관리하는 SNS 서비스를 만든다.
목표
- 여행의 여정 정보를 기록하고 조회하는 [ToyProject 2단계] RESTful API 고도화한다.
- Spring Security 를 활용할 수 있도록, 사용자 테이블 추가 설계한다.
- Spring Security 기반 인증/인가 구현한다.
- MyBatis 또는 JPA를 활용하여 데이터베이스 연동한다.
- 타인의 여행정보에 좋아요, 댓글 기능 구현한다.
- 내가 ‘좋아요’ 누른 여행에 대한 목록 조회 기능 구현한다.
- 전체 여행 중 검색어에 맞는 여행 정보 조회(=검색) 기능 구현한다.
- 레이어 별 (Repository, Service, Controller) 테스트케이스 작성한다.
- 네이버맵, 카카오맵, 구글맵 API 활용하여 위치 정보 표현한다.
서비스 설계
패키지 구조
✅ Domain 형 구조
각각의 도메인 별로 패키지 분리가 가능하여 도메인 별 관리가 직관적입니다. 도메인 별로 의존하는 코드가 없도록 설계가 되었기 때문에 추후에 기획이 추가되더라도 코드를 재활용할 수 있기에 domain형 구조를 선택했습니다.
✅ MVC 구조
Domain 형 구조를 토대로 Model을 담당하는 dto, 입출력을 담당하는 View, service를 담당하는 Main로 MVC구조를 표현했습니다.
요구사항 분석
- ToyProject#2 에 회원을 추가한다,
- 회원은 모든 회원들의 여행 정보를 리스트로 전체 조회할 수 있다.
- 전체 여행 리스트는 여행 정보만 조회한다.
- 각 여행에 포함된 여정 정보들은 개별 조회로 별도 조회한다.
- 회원은 모든 회원들의 여행 정보를 각각 상세 조회할 수 있다.
- 상세 조회 시 해당 여행 정보에 포함된 여정 정보들을 모두 조회한다.
- 회원은 검색어를 통해 조건에 맞는 여행 정보를 검색할 수 있다.
- 여행은 ‘좋아요’ 개수를 추가로 가진다.
- 회원은 본인이 ‘좋아요’를 누른 여행 리스트를 조회할 수 있다.
- 여행 정보에 댓글을 달 수 있다.
- 여행 정보 조회 시 ‘댓글’ 리스트도 같이 출력한다.
- 위치 정보는 오픈 API를 사용하여 표현한다.
- 모든 Data는 JSON으로 반환한다.
ERD

서비스 기능
기능설명

입출력화면
이번 Toy #3 Project에서는 Spring REST Docs를 도입하여 API를 문서화했다.
입출력화면은 아래 RES Docs 링크를 통해 확인할 수 있다.
📜[9조] Toy Project 3 : Spring REST Docs
개발을 진행하면서 Postman을 통해 API test를 진행했다.
이번 프로젝트에서는 댓글과 관련된 CRUD와 여정 Delete API를 맡아 개발을 진행했고, 테스트 결과는 다음과 같다.
역할 분담

⚡ 팀원들의 이름은 비공개처리했다.
내가 맡은 업무는 총 4가지였다.
- 여정 삭제 API
- 댓글 등록 API
- 댓글 수정 API
- 댓글 삭제 API
팀 협업
- 애자일 방법 선택
- 계획 → 설계 → 개발 → 테스트 → 피드백 순으로 프로젝트를 시작한 후 끊임없이 개선에 노력했다.
- 프로젝트 첫째 날에 전반적인 계획 및 설계를 마무리하고, 이후로 개발을 시작하면서 부족한 계획 및 설계를 보완하면서 진행했다.
- 중도에 DB 설계를 바꾸게 되면서 요구사항을 바꾸어 유연하게 개발을 했다.
- CI 전략
- Github Action을 통한 CI 전략을 추가하여 안정적으로 PR을 진행했다.
- 결과적으로 develop 브랜치에 안전한 코드들로 유지할 수 있었다.
- Git-Flow 전략
- main, develop, feature 등 git flow 전략을 사용하여 협업을 진행했다.
- 고정적인 회의 시간
- 매일 오후 2시, 오후 5시에 회의를 진행했다.
- 오후 2시 : 하루 동안 개발한 상황 공유
- 오후 5시 : 2시 이후 개발을 하면서 생긴 질문사항 등을 공유
- 추가적으로 회의가 필요하다면 시간을 내어 회의를 진행했다.
개인공부 정리
이번 프로젝트를 통해 배운점
- @NotBlanck, @NotEmpty, @NotNull 차이점
- 물리삭제 & 논리삭제
- Setter 지양, 그리고 DTO를 써야하는 이유
- BaseTimeEntity.java란 ?
Trouble Shooting 🚀
⚡구체적인 Trouble Shooting은 자체 포스팅에 구체적으로 작성해뒀다.
1. NULL 값 유효성 체크
⚠️ 문제 상황
‘java.lang.Long’ 타입에서 @NotEmpty
를 붙일 수 없어서 생긴 문제
✅ 해결 방안
Long Type에서는 @NotNull
로 수정
🔗 구체적인 Trouble Shooting
2. QueryDSL 빌드 에러
⚠️ 문제 상황
해당 에러가 발생하는 경우는 Q Object(객체)를 생성해야 하는데 이미 폴더나 객체가 생성되어 있어서 발생
✅ 해결 방안
IntelliJ의 우측 Gradle 탭에서 build > clean 클릭
🔗 구체적인 Trouble Shooting
프로젝트를 마무리하며 .. 🐣
Toy Project 마지막 단계를 드디어 마무리했다. 이전 2 단계의 프로젝트 때보다, 확실히 Spring Boot에 대한 이해도 높아져서 개발하는데에 시간이 적게 들 수 있었다. 2단계 project에서 JPA의 부족함을 느껴, 3단계 프로젝트를 시작하기 까지, JPA를 적극적으로 공부한 덕분에, 매핑관계를 이해하기 수월해졌다.
또한, 지금까지 같이한 팀원들과 일정 조율 및 의사소통이 가장 잘 되었던 프로젝트였다. 앞선 2단계 동안 서로의 소통 방식을 배우고, 협업방식을 조율해 나아가면서 마지막 프로젝트는 원활하게 협업할 수 있었다. 그러므로 이전 단계에서 발생한 팀원간의 스케줄 미스 커뮤니케이션을 줄일 수 있었다.
앞으로 Mini Project에서는 FE개발자 분들과 협업을 하게 된다. 지금까지 BE개발자와만 협업을 했던 터라, FE개발자와 협업하는 순간을 기다려왔었고 그 날까지 부족한 부분을 열심히 채워야겠다. FE 개발자와 협업시, 가장 중요한 API 문서 작성 방법을 미리 숙지하고, 일정에 맞춰 API를 개발 완료하기 위해 추가적인 Spring Boot 공부를 해봐야겠다. 🌱
Uploaded by N2T