7주차: 스프링 데이터 JPA, API 문서화, 커밋과 이슈

📚7주차: 스프링 데이터 JPA, API 문서화, 커밋과 이슈

• 스프링 데이터 JPA 만들기
• Query 메소드 작성하기, JPQL(대부분 spring data jpa로 하고 한두개 정도만 해보기)
• API문서화: API 명세서를 작성해보자. API 명세서란?
• ERD(Entity Relationship Diagram) 그리기(작성툴 : https://www.erdcloud.com/ ), 참고(→ API 명세서, ERD 참고 : https://satin-loganberry-da5.notion.site/0701-e2e9ce3bf718444b85d041cf97b21fde?pvs=4)
• 로그인 및 회원가입, validation 처리 → 할 수 있다면 카카오 로그인으로 해보기
• 커밋 컨벤션과 이슈 작성하기(참고 : https://jae04099.tistory.com/entry/GIT-커밋에-관하여좋은-커밋-메시지-커밋-타이밍-등
  • [Feat] #12 게시물 삭제 기능 추가
    (한줄 띄우고)
    설명설명~~))
• 패키지 구조 설정(도메인형 추천) 참고 : https://velog.io/@jsb100800/Spring-boot-directory-package
• PR(Pull Request)란? 무엇인지 개념만
• 깃허브 이슈
• 커밋 컨벤션

---

스프링 데이터 JPA 만들기

• JPA로 CRUD 구현 ✅
• 시간날 때 페이지네이션 해보기 …

Query 메소드 작성하기, JPQL(대부분 spring data jpa로 하고 한두개 정도만 해보기)

• JPQL이란?
  • JPQL은 엔티티 객체를 조회하는 객체지향 쿼리이다. 따라서 테이블을 대상으로 쿼리하는 것이 아니라 엔티티 객체를 대상으로 쿼리한다. 문법은 SQL과 유사하며 간결하다. JPQL은 결국 SQL로 변환된다.
  • 또한 JPQL은 SQL을 추상화해서 특정 데이터베이스에 의존하지 않기 때문에 데이터베이스 방언만 변경하면 JPQL을 수정하지 않아도 다른 데이터베이스에 쓸 수 있다.

public BoardDTO findById2(Long id) {
        BoardEntity boardEntity = em.createQuery("SELECT * FROM board_table b WHERE b.id", BoardEntity.class)
                .setParameter("id", id)
                .getSingleResult();

        BoardDTO boardDTO = BoardDTO.toBoardDTO(boardEntity);
        return boardDTO;

    }

API문서화: API 명세서를 작성해보자. API 명세서란?

게시판

ERD(Entity Relationship Diagram) 그리기(작성툴 : https://www.erdcloud.com/ ), 참고(→ API 명세서, ERD 참고 : https://satin-loganberry-da5.notion.site/0701-e2e9ce3bf718444b85d041cf97b21fde?pvs=4)

(대략 그려본 erd) 많은 수정 필요

로그인 및 회원가입, validation 처리 → 할 수 있다면 카카오 로그인으로 해보기

• @Valid: save시 중복 검증

@PostMapping("/api/v1/save")
    public CreateBoardResponse save(@RequestBody @Valid BoardDTO boardDTO) {
        Long id = boardService.save(boardDTO);
        return new CreateBoardResponse(id);
    }

    @Data
    static class CreateBoardResponse {
        private Long id;

        public CreateBoardResponse(Long id) {
            this.id = id;
        }
    }

디렉토리 구조 변경하기(계층형→도메인형)

참고 자료 보기

[Spring boot] 디렉터리 패키지 구조의 선택

• 나는 지금까지 Spring boot를 활용한 API 서버를 개발할 때, 디렉터리 구조를 스프링 웹 계층형 구조를 기반으로 패키징 했다. 이러한 패키징 방식은 Controller, Service, Repository, Domain과 같이 각각의 웹 계층을 대표 혹은 구성하는 클래스들로 이루어진다.
• 계층형 방식의 단점과 개선점들 때문에 다른 방식의 디렉터리 패키징 구조를 알아보자

🚨 계층형 디렉터리 구조

✅ 도메인형 디렉터리 구조

• 해당 방식은 스프링 웹 계층에 주목하기 보다는 도메인에 주목한다. 이를 통해서 각각의 도메인 별로 패키지 분리가 가능하여 관리에 있어서 계층형 방식보다 직관적이며, 각각의 도메인들은 서로를 의존하는 코드가 없도록 설계하기 적합해서 코드의 재활용성이 향상된다.

• 최상위 레벨의 패키지

  • 최상위 레벨에서는 domain과 global로 패키징한다.
  • domain 패키지에서는 프로젝트와 DB 구조에서 핵심 역할을 하는 domain entity를 기준으로 하위 패키지를 구성한다.
  • global 패키지에서는 프로젝트 전방위적으로 사용할 수 있는 클래스 들로 구성된다.
    • ex) config

• domain 하위 패키지

  • user, video와 같이 핵심 domain entity 별로 패키지가 구성된다.
  • 각각의 domain 하위 패키지는 api, application, dao, domain, dto, exception 패키지로 구성된다.
  • api: controller 클래스가 존재한다. 해당 프로젝트에서 스프링 부트는 Rest API로서 역할만을 하기 때문에, 명시적으로 api라는 네이밍으로 패키징한다.
  • application: 주로 service 클래스들이 존재한다.
  • dao: dao, repository 클래스들로 구성된다.
  • domain: entity 클래스들로 구성된다.
  • dto: dto 클래스들로 구성된다.
  • exception: exception 클래스들로 구성된다.

• global 하위 패키지

  • 해당 패키지에는 특정 domain에 종속되지 않고, 프로젝트 전방위적으로 사용할 수 있는 클래스들이 모여있다.
  • global 패키지는 auth, common, config, error, infra, util 패키지로 구성된다.

✅결론

도메인형 디렉토리 구조를 적용함으로써 더 직관적으로 프로젝트를 관리할 수 있다.

코드의 재사용성이 올라간다.

패키지 방식에 정답은 없기 때문에 자신만의 패키징을 추가하면서 발전시켜나가야 한다.

결국 가장 올바른 패키지 방식은 개발자가 관리하기 쉬운, 능률을 향상 시키는 패키지 방식인 것 같다.

🚨내 계층형 디렉토리 구조를 도메인형 디렉토리 구조로 리팩터링 해보기

현재 내 디렉터리 구조

└─com
    └─example
        └─dcInsideClone2
            ├─api
            ├─controller
            ├─dto
            ├─entity
            ├─repository
            └─service

✅도메인형 디렉터리 구조를 적용

PR(Pull Request)란? 무엇인지 개념만

• 내가 직접 PUSH 권한이 없는 프로젝트를 fork 후 clone하여 코드를 작성한 후 PR을 요청하여 코드 작성에 기여할 수 있다.
• 작업의 충돌 방지 및 PR단위로 코드를 확인 할 수 있다

깃허브 이슈

💡 *issue  :  프로젝트를 진행하면서 발생하는 모든 이슈 (버그 발생, 개발, 풀 리퀘스트 등등)*

깃헙에서는 이슈기능을 통해 프로젝트에서 발생하는 모든 문제를 관리할 수 있도록 돕는다. 이슈는 아래 이미지와 같이 제목과 이슈에 대한 설명을 작성하여 생성할 수 있다.

커밋 컨벤션

• 구조

type : subject

//제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
//영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제를 사용하지 않는다.)
//제목은 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미.

body

// 본문은 한 줄 당 72자 내로 작성한다.
// 본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
// 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.

footer 

// 꼬리말은 optional이고 이슈 트래커 ID를 작성한다.
// 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.

• 커밋 타입

태그 : 제목의 형태이며, :뒤에만 space가 있음에 유의한다.

• feat : 새로운 기능 추가

• fix : 버그 수정

• docs : 문서 수정

• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

• refactor : 코드 리펙토링

• test : 테스트 코드, 리펙토링 테스트 코드 추가

• chore : 빌드 업무 수정, 패키지 매니저 수정

• 예시

Feat: "회원 가입 기능 구현"

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

• 커밋 메시지 이모지

Emogi	Description
🎨	코드의 형식 / 구조를 개선 할 때
📰	새 파일을 만들 때
📝	사소한 코드 또는 언어를 변경할 때
🐎	성능을 향상시킬 때
📚	문서를 쓸 때
🐛	버그 reporting할 때, @FIXME 주석 태그 삽입
🚑	버그를 고칠 때
🔥	코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜	파일 구조를 변경할 때 . 🎨과 함께 사용
🔨	코드를 리팩토링 할 때
💄	UI / style 개선시
♿️	접근성을 향상시킬 때
🚧	WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎	New Release
🔖	버전 태그
✨	새로운 기능을 소개 할 때
⚡️	도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡	새로운 아이디어, @IDEA주석 태그
🚀	배포 / 개발 작업 과 관련된 모든 것

Git | git 커밋 컨벤션 설정하기