README.md

BE-HandTris

👉 핸드 모션 캡처로 즐기는 실시간 1:1 대결 테트리스

프로젝트 아키텍쳐

ERD

Use Case

0. 개발 환경, 언어, 도구

• Intellij
• Data JPA
• JDK 21
• Mysql
• Redis (Cache DB)
• Docker
• Terraform
• Github Action
• Junit
• Mockito
• Prometheus
• Grafana
• PostMan (API Test)

1. 코딩 컨벤션

Entity Class

• 필드명은 전부 camelCase 로 작성
• Class Name은 PascalCase 로 작성

Package Naming

• Domain 별로 패키지를 분리한다.
  • ex.) 회원, 채팅방이 존재한다면 member,chat등의 큰 단위의 Domain으로 분리한다.
• Controller는 api,Service는 application,Repository는 repo로 Naming하여 기능별로 분리
  • Service의 경우 impl과 service로 나누어 DIP 준수
• DTO와 Entity는 별도의 패키지에서 관리하며, DTO내부는 Request와 Response 용도에 따라 패키지를 따로 두어 분리한다.
  • DTO는 Inner Class 방식을 사용한다.
  • Naming의 경우 MemberDTO의 경우, 회원가입과 정보조회 DTO는 다음과 같이 SignUp,CheckInfo로 정정한다.
• ex)

root
├── README.md
├── build
│   ├── classes
│   │   └── java
│   │       └── main
│   │           └── jungle
│   │               └── HandTris
│   │                   ├── HandTrisApplication.class
│   │                   ├── application
│   │                   │   ├── impl
│   │                   │   └── service
│   │                   ├── domain
│   │                   │   ├── exception
│   │                   │   └── repo
│   │                   ├── global
│   │                   │   ├── config
│   │                   │   │   ├── log
│   │                   │   │   ├── security
│   │                   │   │   └── ws
│   │                   │   ├── discord
│   │                   │   │   └── model
│   │                   │   ├── dto
│   │                   │   ├── exception
│   │                   │   ├── filter
│   │                   │   ├── handler
│   │                   │   ├── jwt
│   │                   │   ├── util
│   │                   │   └── validation
│   │                   └── presentation
│   │                       └── dto
│   │                           ├── request
│   │                           └── response
│   ├── resources
│   │   └── main
│   │       ├── db
│   │          └── migration
├── build.gradle
├── docker
│   ├── Dockerfile
│   ├── docker-compose.yml
│   └── monitor
│       ├── grafana
│       │   └── dashboards
│       │       └── dashboards.yml
│       └── prometheus
│           └── prometheus.yml
├── docs
│   ├── API_Documentation.md
│   ├── ERD.md
│   ├── UseCase.md
│   └── images
│       ├── ApiDocumentation.png
│       ├── ERD.png
│       └── UseCase.png
├── infra
│   ├── alb.tf
│   ├── ec2.tf
│   ├── handtris.pem
│   ├── network.tf
│   ├── provider.tf
│   ├── rds.tf
│   ├── route.tf
│   ├── variable.tf
│   └── version.tf
│   │   └── resources
│   │       ├── application-S3.yml
│   │       ├── application-dev.yml
│   │       ├── application-jwt.yml
│   │       ├── application-prod.yml
│   │       ├── application.yml
│   │       ├── console-appender.xml
│   │       ├── db
│   │       │   ├── locust_dummy.sql
│   │       │   └── migration
│   │       │       ├── V1__init.sql
│   │       │       └── V2__delete_avg_time_member_record.sql
│   │       ├── discord-appender.xml
│   │       ├── logback-dev.xml
│   │       └── logback-prod.xml

File Naming

• YML파일은 Kebab Case 로 Naming한다.
• DB 설정 및 프로젝트에 필요한 설정들은 application.yml 에 저장하여준다.
• jwt,aws,mail등을 별도의 yml파일을 만들어 관리한다.

API 요청 URl

• 동사를 사용하지 않는다.
• RestFul한 네이밍을 사용한다.
• ex.) ${domain_name}s/

DB & CI/CD

• AWS EC2에 운영서버를 운영하며 Github Action과 Docker를 이용하여 CI/CD를 구축
• Mysql DB는 RDS에 운영중이며, 같은 VPC가 아니라면 접근불가

2. 레파지토리 관리 기법

Organization에서 BackEnd 별도의 레파지토리에서 관리합니다.

⚙️ 브랜치 관리 전략

⚙️ Git-flow

⚙️ 브랜치 구성

• feat 브랜치는 하나의 기능을 개발하기 위한 브랜치입니다. 부모는develop이며, 개발이 완료되면develop에 merge합니다. 브랜치 이름은 보통feature/*이 됩니다.
• dev 브랜치는 개발을 위한 브랜치입니다. 여러feature들이 merge되는 장소이며, 아직 release되지 않은 기능들이 모여 있게 됩니다.
• main브랜치는 실제 운영 중인 서비스의 브랜치입니다.
• hotfix브랜치는 서비스에 문제가 발생했을 때 핫픽스에 해당하는 브랜치입니다. 기능 개발(feature) 등과 달리 빠르게 대처해야 할 필요가 있기 때문에,master브랜치에 직접 merge하는 전략을 취합니다.dev과의 차이가 발생하기 때문에, 나중에 차이를 merge할 필요가 있습니다.

🛠 Git Branch workflow

• Squash and Merge 방법을 차용하여 Issue,Feature 단위 커밋을 통해 Merge시 진행 사항 구조 손쉽게 파악하는 것을 목적으로한다.
• 각 branch PR시 이슈화하여 코드에 대한 피드백 및 토론 후 상대방이 Merge

브랜치 네이밍

⚙️ 네이밍 패턴

#이슈번호

Ex) 이슈번호가 67인 '로그인 기능' 이슈를 구현하는 브랜치를 생성하는 경우, 브랜치 이름을#67로 작성한다.

커밋 메시지

⚙ 메시지 구조

Type : 제목 #이슈번호

본문

**Ex)**이슈번호가 67인 이슈의 기능을 구현한 뒤 커밋을 하는 상황이라면 커밋 메시지의 제목을feat : A기능 구현 #67으로 작성한다.

⚙ Type

• feat : 새로운 기능에 대한 커밋
• fix : 버그 수정에 대한 커밋
• docs : 문서 수정에 대한 커밋
• style : 코드 스타일 혹은 포맷 등에 관한 커밋
• refactor : 코드 리팩토링에 대한 커밋
• test : 테스트 코드 수정에 대한 커밋
• chore : 패키지 관련 및 빌드코드 수정

3. 소개 포스터

• 사진

개발기간

2024 06 20 ~ 2024 07 20