SpringBoot + Kotlin taxi scenario
- Kakao 및 Kakao mobility API 연동으로 조회한 정보를 사용하여 택시기사/사용자 관점에서 택시 호출/배정/결제 등의 기능을 구현한 택시 애플리케이션 프로젝트
- Sept.16th.2023 ~ Oct.13th.2023
- Spring Boot : 3.1.3
- spring-boot-starter-data-jpa
- spring-boot-starter-web
- spring-boot-starter-validation
- jackson-module-kotlin
- kotlin-reflect
- spring-boot-starter-aop
- spring-boot-starter-test
- testcontainers:1.19.1 TC 의존성
- mysql:1.19.1 MySQL
- Gradle : 8.2.1
- Test tool : JUnit5
- Kotlin : 1.8.22
- JAVA : corretto 17 ver.
- ORM : JPA (Hibernate), KotlinJDSL
- DB : RDS (MySQL)
- Infra : Docker, AWS ECR, ECS, FARGATE
- VCS : Git / GitHub
- IDEA : IntelliJ
- Cooperation tool : JIRA & SLACK & Gather
![image](https://private-user-images.githubusercontent.com/38535971/274923808-ec400cf4-1858-41c9-9db9-3705ef46b726.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjUyOTcxNzksIm5iZiI6MTcyNTI5Njg3OSwicGF0aCI6Ii8zODUzNTk3MS8yNzQ5MjM4MDgtZWM0MDBjZjQtMTg1OC00MWM5LTlkYjktMzcwNWVmNDZiNzI2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MDIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTAyVDE3MDc1OVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWJmZmRkNDE2YjI5NjkwM2Y4NTE3MGVlZmMzN2M3YWQ4MjgzYWU3NGZkOGNiNjdhM2FkNTFkNDM4MzliMDU2NmEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.7fV0nRJWbnX54sI4kxyNUM08KU0e78c4x9SOdenwGBA)
Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다. 그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.
이러한 이유가 있지만, Git Flow의 흐름 및 전체적인 구조를 파악하는데 좋은 레퍼런스가 되며, 대부분의 기업과 우리는 Git Flow가 익숙하기 때문에 GitHub Flow
보다는 Git Flow
를 사용하고 있어요.
각 개발 메인 브랜치는 Dev, Prod를 메인으로 두고 있어요. 이 두개의 브랜치에서 Feature 브랜치가 생성되요. 각 Feature 브랜치는 기능 기준으로 만들어집니다.
Ex) 사용자 등록 기능을 만들면 feature/lil/createAddUser
식으로 만들게 되죠.
- 그리고 각 feature 브랜치를 생성하고 기능 개발이 끝나면 PR( Pull Request)를 생성하여, 팀원들의 코드리뷰를 받게됩니다.
- feature 브랜치의 코드리뷰가 끝나면 Dev 브랜치로 Merge가 되고, Dev 브랜치는 Prod로 Push를 하게 되는거죠.
- 언제든지 생길 수 있는 다양한 버그들에 대해서 서로 알기 쉽게 알아볼 수 있도록 했어요.
## 버그 설명
[버그에 대한 명확하고 간결한 설명]
## 재현 단계
[버그를 재현하기 위한 단계]
## 예상 동작
[예상했던 동작과 실제 동작의 차이]
- 각자의 기능 브랜치에서 작업하지만 필요에 따라서 요청시 규격화된 이슈를 남기기로 했어요.
## 기능 제안
[제안하는 기능에 대한 명확하고 간결한 설명]
## 예상 동작
[새로운 기능이 추가되면 어떻게 동작해야 하는지 설명]
## 추가 정보
[기능 제안에 대한 추가적인 정보나 컨텍스트]
- 우리는 중구난방의 PR 메세지 및 아주 커다란 커밋의 크기를 정하기로 했어요.
# 해결하려는 문제가 무엇인가요?
*
# 어떻게 해결했나요?
*
## Attachment
[ PR도 최대한 작은 단위로 쪼개서 올리기 ]
[ Merge는 적어도 하나의 Approve가 있어야해 ]
- 반드시 기기에 자바와 코틀린이 설치되어 있는지 확인해주세요.
- 이 리파지토리를 복제해 주세요:
git clone https://github.com/KATJ-HH2/katj.git
cd KATJ-HH2
./gradlew build
./gradlew run
Open your web browser and go to 헬스체크 url
-
EndPoint: POST ‘/taxidrivers/info’
Function: 택시기사 정보와 택시 정보를 등록합니다 -
EndPoint:
-
GET ‘/taxidrivers/status’
-
PUT ‘/taxidrivers/status’
Function: 택시 운행 상태를 변경하거나 조회합니다 -
EndPoint: GET ‘/trip/info’
Function: 운행 예상경로와 요금 정보를 조회합니다
-
사용자가 호출 요청 (수동 호출) TripController.userCallTaxi(kakaoAPI 조회 반환값, 사용자id) -> trip 생성, TripStatus.CALL_TAXI
-
택시 (랜덤) 배정 (자동 호출) TripStatus.CALL_TAXI -> 운행 가능 택시 랜덤 조회(없더라도 5초간 지속 조회) -> 사용자에게 택시 랜덤 배정 --> TripStatus.ASSIGN_TAXI(TaxiDriver.WAITING -> ASSIGNMENT)
-
보류 - 사용자가 호출 취소(opt) 보류 - 택시기사가 호출 취소(opt)
-
택시 운행 중 (수동 호출) TripController.taxiDriveStart(tripId) -> TripStatus.DRIVING(TaxiDriver.START_DRIVING)
-
택시 운행 완료 (수동 호출) TripController.taxiDriverEnd(tripId) -> TripStatus.END -> TaxiDriver.END_DRIVING -> TaxiDriver.WAITING
-
사용자에게 결제 요청 -> TripStatus.END -> 사용자 결제 로직
-
EndPoint: GET ‘/trip/totalfare’
Function: 당일 운임료 합계를 조회합니다
-
EndPoint: POST ‘/location’
Function: 검색어로 주소 정보 조회 및 이력을 저장합니다. -
EndPoint: POST '/route'
Function: 출/도 주소 정보로 요금 정보 조회 및 이력을 저장합니다.
-
EndPoint: GET ‘/favorite?userId=’
Function: 사용자의 모든 즐겨찾기를 조회합니다 -
EndPoint: GET ‘/{favoriteId}?userId=’
Function: 사용자가 해당 즐겨찾기를 조회합니다. -
EndPoint: POST ‘/favorite?userId=’
Function: 사용자가 즐겨찾기를 추가합니다. -
EndPoint: PUT ‘/{favoriteId}?userId’
Function: 사용자가 해당 즐겨찾기를 수정합니다. -
EndPoint: DELETE ‘/{favoriteId}?userId’
Function: 사용자가 해당 즐겨찾기를 삭제합니다. -
EndPoint: DELETE ‘/delete-multi?userId’
Function: 사용자가 여러개의 즐겨찾기를 삭제합니다. -
EndPoint: DELETE ‘/delete-all?userId’
Function: 사용자의 모든 즐겨찾기를 삭제합니다.
-
EndPoint: GET ‘/payment-method/{paymentMethodId}?userId=’
Function: 사용자가 해당 결제 수단을 조회합니다. -
EndPoint: GET ‘/payment-method?userId=’
Function: 사용자가 모든 결제 수단을 조회합니다. -
EndPoint: POST ‘/payment-method/bank-account?userId=’
Function: 사용자가 은행 계좌를 결제 수단으로 등록합니다. -
EndPoint: POST ‘/payment-method/card?userId=’
Function: 사용자가 카드를 결제 수단으로 등록합니다. -
EndPoint: POST ‘/payment-method/valid/bank-account?userId=’
Function: 사용자가 등록 하려는 계좌의 유효성을 외부 API를 통해 인증합니다. -
EndPoint: POST ‘/payment-method/valid/card?userId=’
Function: 사용자가 등록 하려는 카드의 유효성을 외부 API를 통해 인증합니다. -
EndPoint: DELETE ‘/payment-method/{paymentMethodId}’
Function: 사용자가 등록된 결제 수단을 하나 삭제합니다. -
EndPoint: DELETE ‘/payment-method’
Function: 사용자가 등록된 결제 수단을 모두 삭제합니다.