기획 및 설계 (기능명세서, API, ERD)

프로젝트 소개

프로젝트명 : 테니스 투게더
프로젝트 기간 : 2021.10.12 ~ 2021.11.30
주요 기능

• 로그인, 회원가입(구글 Oauth 인증, Spring Security 기반 )
• 테니스장 조회 (kakao지도 api)
• 경기 모집글 및 댓글 CRUD
• 모집글 수락 및 거절
• 친구 등록
• 게임 한 유저 리뷰 작성
• 유저 프로필 수정

기술 스택

• frontend : react, javaScript, html/css
• backend : java, spring boot, JPA, spring security
• Database : postgreSQL
• CI/CD : github actions, heroku
• etc : firebase storage, firebase oAuth
  

 

 

카우치 코딩이라는 곳에서 멘토님들의 도움을 받아 다른 개발자분들 함께 6주간 프로젝트를 하나 시작하게되었다!!

프로젝트의 주제는 이름은 "테니스 투게더" 쉽게 말해 테니스를 함께 할 친구를 찾는 사이트이다.

팀원은 프론트 2명 / 백엔드 3명 총 5명이다. 여기서 나는 백엔드 개발 파트를 맡았다.

Java/spring 프로젝트를 거의 3년만에 처음 해보는 것이다 보니 기억도 가물가물하고..

한번도 안써본 기술들도 많아서 해야될 것들이 너무 많다.

직장을 다니면서 병행하려면 정말 부지런히 해야할 것 같다!! 화이팅!!!

 

기능명세서

처음엔 채팅도 있고, 지도로 테니스장 조회하는 것도 있고, Oauth 로그인도 여러개, 친구 신청 및 거절 등등..

수많은 기능들이 있었지만 회의를 할수록 기능을 단순화하고 핵심로직에 집중하려고 했다.

멘토님이 피드백을 통해 기획에서 불필요한 부분을 많이 다듬어 주셔서 기획을 마무리 하는데 많은 도움이 되었다

https://www.notion.so/5856162f5b9e494f8b874d5cc23847bc

기능명세서

 

 

API

테이블의 PK를 복합키로 설정한 부분은 api 설계할 때도 두 개의 key 를 www.xx.com/keyA/keyB 와 같이 보내는 방식으로 설계를 했었는데, 그렇게 하면 URI가 복잡해지고 의미를 식별하기도 어렵다는 피드백을 받았다.

복합키 대신 의미가 없는 대체키를 테이블에 만들어서 그것을 PK로 API설계를 변경하였다.

나중에 JPA Entity 매핑을 하면서 더 느낀 거지만 테이블에 pk를 복합키로 사용하면 뭔가 더 생각해야할게 많아진다..

꼭 필요한 경우가 아니면 사용하지 않는 편이 좋겠다

HTTP 정리

 

https://www.notion.so/API-8817ad4aae54409cbce3f1a89452f2d3

API

 

 

 

ERD

ERD작성은 ERD 클라우드 라는 무료 ERD도구를 사용하였다.

항상 쿼리를 기반으로 데이터를 관리하고 작업을 하고 테이블 조인을 하는 것에 익숙해져 있었고 내가 지금 일하면서 주로 쓰는 방식대로 ERD를 설계 하였는데, JPA를 사용하며 객체와 테이블의 관계를 매핑하다 보니 매끄럽지 못한 부분들이 많았다.

이 부분은 앞으로 공부가 좀 더 필요할 것 같다.

https://www.notion.so/ERD-485b1bf4cd464f2884e3518fff6d1f06

ERD