프로젝트 개요

프로젝트 개요 (프로젝트 구현 내용, 컨셉, 훈련내용과의 관련성 등)
- 프로젝트 구현 내용
- 소셜 로그인을 통해 로그인할 수 있다.
- 북마크를 추가, 수정, 삭제할 수 있다.
- 북마크를 등록할 때 북마크 url에 해당하는 이미지, 제목 정보를 알 수 있다.
- 여러 필터링 기능을 이용해 북마크를 조회할 수 있다.
- 다른 사용자에게 내 북마크를 공유할 수 있다.
- 다른 사용자의 북마크에 반응(좋아요, 싫어요)할 수 있다.
- 내 북마크와 다른 사용자 북마크를 즐겨찾기 할 수 있다.
- 다른 사용자를 팔로우 할 수 있다.
- 다른 사용자를 검색할 수 있다.
- 훈련내용과의 관련성
- Java, Spring, Spring MVC, Spring Data JPA, Spring Security, AWS, MySQL, GitHub 등 훈련 기간중에 배운 다양한 기술을 활용해 프로젝트를 진행함.
활용 장비 및 재료(개발 환경 등)
- 사용 기술
- JAVA 11
- Gradle 7.4.1
- JWT
- Flyway
- Querydsl
- Spring Boot 2.7.1
- Spring Web
- Spring Data Jpa
- Spring Security
- Spring Rest-Docs
- 인프라
- Mysql
- H2
- AWS (EC2, RDS, S3)
- Docker
- GitHub Actions
- Jenkins
- NGINX
- 테스트
- JUnit
- Jacoco
- Postman
- 협업
- Git
- GitHub
- Jira
- Slack
- Notion
프로젝트 구조
- 프로젝트 폴더 구조 (그림 첨부)

프로젝트 수행 결과

- 결과물
- ERD, API Docs, 프로젝트 설계, CI/CD, 인프라, 테스트 코드, Demo
ERD
개발하고자 하는 서비스의 도메인을 파악하고 이에 맞게 테이블을 설계함.

사용자의 소셜 로그인 정보와 프로필 정보는 서비스 로직에서 분리돼 사용하는게 좋다고 판단해 사용자 테이블과 프로필 서비스를 나눔.
북마크와 태그는 ManyToMany 관계이기 때문에 북마크_태그 테이블을 이용해 OneToMany와 ManyToOne으로 관계를 설정함.
알림은 테이블의 알림 정보는 추후 확장성을 고려해 JSON 타입 사용함.
API
API 엔드포인트는 리소스를 식별하도록 설계했다. API에 대한 행위는 HTTP 메서드를 이용해 표현했다.

CI/CD 설계
- GitHub Actions를 활용해 devlop 브랜치에 머지하기 전 코드 이상 유무 확인
- Jenkins를 활용해 CI/CD 자동화

핵심 기능
- 다양한 필터링 기능 제공
- 다양한 필터링 기능을 JPQL을 이용해 만들려면 중복되는 코드가 증가한다. 이런 문제를 QueryDsl을 활용해 해결했다.
- 다양한 필터링 기능을 쿼리 파라미터로 받기위해 custom Resolver 개발


프로젝트 설계도
계층형 아키텍처를 기반으로 설계했다.
컨트롤러 계층 → 서비스 계층 → 영속성 계층
계층 관계를 지키면서 개발하기 위해 의존성 검사해주는 테스트를 작성했다. 이를 활용해 계층간 의존성이 깨지지 않게 주의하면서 개발했다.

서비스에서 다른 도메인의 엔티티가 필요한 경우 서비스에 의존하는 방법과 레포지토리에 의존하는 방법 둘다 마음에 들지 않았다. 그래서 조회용 컴포넌트를(@Query) 만들었다.
서비스에서 다른 도메인의 엔티티가 필요한 경우 쿼리 컴포넌트에 의존해 엔티티를 얻어온다. 하지만 서비스에서 다른 도메인 데이터에 영향을 주는 로직이 필요하다면 서비스에 의존하도록 설계했다. 이 경우 순환 참조가 발생하지 않도록 주의했다.

테스트 코드
프로덕션 코드의 안전성을 위해 테스트를 꼼꼼이 했다.
결과적으로 약 200개의 테스트 코드를 작성했다. 덕분에 과감한 리팩토링이 가능했다.


CI/CD & 인프라 설계도
CI/CD는 GitHubActions와 Jenkins를 이용해 설계했다. 인프라는 AWS의 EC2, RDS, S3를 사용한다.
develop 브랜치에 CI/CD가 적용된다.
서버는 3가지로 나눈다.
- local server : 개발자들이 개발하는 서버 (자신의 노트북)
- dev server : github의 develop 브랜치와 동일한 코드가 올라가 실행되고 있는 서버
- prod server : main 브랜치와 동일한 코드가 올라가 실행되고 있는 서버
GitSub Module
인프라에 대한 정보들을 외부에 노출시키지 않기 위해 생각해보았고
git submodule를 통해 public repository에 db 에대한 정보들(id/password) 등등을 private하게 관리가능하게 되었습니다.
Fly Way
데이터베이스를 밀지 않고 히스토리로 데이터베이스 관리함
DB를 버전관리를 통해 관리
Demo
추후에 발표자료 만든 후 추가하기.