Hustle #10. 프로젝트 구조 잡기

안녕하세요, 다람쥐입니다.

저번 포스팅에선 Aquery Tool 으로 ERD 모델링을 했습니다.

2023.09.04 - [프로젝트/장기 프로젝트] - Hustle #9. Aquery Tool 으로 ERD 모델링하기

이번 포스팅은 허슬 프로젝트 구조를 잡으려고 합니다.

 

프로젝트 구조는 무엇일까?

프로젝트 구조는 프로젝트를 구성하는 폴더와 파일을 정리하는 방식입니다.

다른 백엔드 프레임워크에서는 정해진 파일명, 정해진 폴더명을 써야 하는 경우가 많은데요.

스프링 부트에서는 어노테이션만 붙이면 스캔하여 클래스를 찾을 수 있습니다.

따라서 프로젝트 구조는 정해지지 않고 마음대로 정할 수 있는데요.

그렇다면 어떻게 프로젝트 구조를 정해야 할까요?

 

허슬의 프로젝트 구조

허슬의 구성 요소는 다음과 같습니다.

• 컨트롤러 (Controller) : API 요청과 응답을 담당합니다.
• 서비스 (Service) : 핵심 비즈니스 로직을 담당합니다. 컨트롤러나 다른 서비스에서 호출합니다.
• DTO : API 요청과 응답을 객체로 관리합니다. 또는 데이터베이스에서 가져온 데이터를 DTO 으로 변환하여 여러 서비스에서 사용합니다.
• 엔티티 (Entity) : 데이터베이스 테이블과 매핑되는 자바 객체입니다. 데이터베이스에서 가져오면 DTO 로 변환하여 애플리케이션 내부에서 사용됩니다.
• 리포지토리 (Repository) : 주로 인터페이스로 데이터베이스 작업을 정의합니다. QueryDSL 을 사용하는 경우 클래스로 직접 데이터베이스 SQL 쿼리를 정의합니다.
• 설정 YML 파일 : 설정 코드를 담당합니다. 설정 정보는 언제든 애플리케이션에서 사용할 수 있습니다. 민감한 정보는 암호화되어 있습니다.
• 예외 클래스 (Expcetion) : 부모 예외를 상속한, 커스텀으로 이름을 지은 예외 클래스입니다.
• 설정 컴포넌트 : @Configuration 어노테이션이 붙은 클래스들입니다. 주로 의존성 라이브러리의 설정 코드를 담당합니다.
• 유틸 클래스 (Utils) : 반복되는 코드를 정의한 클래스입니다. 주로 조회 및 조회 실패 예외 처리를 담당합니다.

 

구성 요소들을 위치시킬 때 특정 패턴이 있습니다.

컨트롤러, 서비스, DTO, 엔티티, 리포지토리는 기능을 구현할 때 마다 반복되는 파일들입니다.

단, 설정과 관련한 파일은 허슬 프로젝트에서 한 파일만 있으면 됩니다.

 

프로젝트 내에서 공통으로 사용하는 부분은 common 폴더로 만들었습니다.

프로젝트 내에 공통으로 적용되는 설정은 common 폴더 하위의 config 폴더에 넣었습니다.

이 외에 common 폴더 하위에 있는 폴더는 아래와 같습니다.

• annotation : 공통 어노테이션 파일
• consts : 상수 파일
• converter : API 요청에서 String 데이터를 특정 Enum 으로 변환
• dto : 프로젝트 내에서 공통으로 적용할 응답 형식을 정의
• entity : 프로젝트 내에서 공통으로 적용할 기본 엔티티 형식 정의
• exception : 프로젝트 내에서 공통으로 적용할 기본 예외 형식 정의
• jwt : JWT 기능 모음
• resolver : 커스텀으로 만든 공통 어노테이션 로직 정의

프로젝트 내에서 공통으로 사용하는 common 폴더 외에는 '기능' 마다 반복되는 파일들입니다.

컨트롤러, 서비스, DTO, Entity 이렇게 하나씩 묶어도 되지만, 허슬 팀은 도메인 단위로 묶었습니다.

처음에 설계된 프로젝트가 작은 사이즈가 아니었기에, 하나에 다 묶어놓으면 관리하기가 어려울 것으로 판단했습니다.

또 컨트롤러와 서비스, DTO, Entity 모두 편집기에서 관련한 파일을 이동하기 편해야 했습니다.

대회 도메인, 동아리 도메인, 유저 도메인 등등으로 분리하여 연관된 구성요소 파일들을 묶었습니다.

 

도메인 폴더마다 아래의 구조를 가집니다.

• Controller 파일 : 컨트롤러 파일, 여러 개 있을 수 있음
• Service 파일 : 컨트롤러 앞 이름과 일치, 여러 개 있을 수 있음
• dto 폴더 : 엔티티 DTO 파일, API 요청 & 응답 DTO 파일, DTO 에서 사용한 Enum 파일
• entity 폴더 : 데이터베이스 스키마를 정의한 클래스 파일
• repository 폴더 : 데이터베이스 작업을 정의한 인터페이스 파일, QueryDSL 으로 직접 데이터베이스 작업을 정의한 클래스 파일 (Custom이 붙음)
• Utils 파일 : 공통 로직을 모은 정적 메소드 파일

 

컨트롤러와 서비스 파일은 보통 도메인에 하나씩 있으므로 따로 폴더로 구분하지 않았습니다.

하나의 컨트롤러가 커지는 경우 여러 개의 컨트롤러와 서비스 파일로 분리했습니다.

하나의 도메인에서도 여러 하위 도메인으로 나뉘는 경우에도 분리했습니다.

비교적 크기가 작은 도메인 (좌) 크기가 커 하위 도메인으로 분리한 도메인 (우)

공통 common 폴더 프로젝트 구조

 

설정 파일은 resources/ 폴더 하위에 한 YML 파일로 관리하고 있습니다.

프로필별로 환경을 관리하지만, 아직 그 양이 적어 한 파일로 관리하고 있습니다.

 

마무리

허슬 프로젝트의 프로젝트 구조를 담았습니다.

프로젝트 구조를 잡으면 유지 보수와 구조 파악이 편해지는 장점이 있습니다.

허슬 팀은 도메인 단위로 나눠 작업을 진행했습니다.

다른 사람이 미리 합의한 프로젝트 구조대로 작업하면, 구조 파악이 수월해집니다.

잘 정리된 수납장처럼 더 이상 어떤 클래스가 어디에 위치하는 지 번거롭게 찾지 않아도 됩니다.

 

다음은 팀원끼리 합의한 스프링 개발 컨벤션과 관련한 이야기를 할 예정입니다.

이제 프로젝트 구조를 합의했으니, 파일 안에 들어가는 코드의 규칙을 정할 차례입니다.

다음 포스팅에서 보겠습니다.