[Spring Boot] 기본 폴더 구성하기 및 연관 관계

팀 프로젝트 시 적용했던 폴더 구조와 상호 연관 관계에 대한 설명

 

 

• 초기 생성 폴더

 

스프링부트 프로젝트를 생성하면 설정한 도메인이 포함된 기본 폴더가 위와같이 생성된다.

여기서 설정 도메인 내에 해당 사이트에서 사용할 하위 도메인을 큰 기능별로 나누어 폴더를 추가해준다.

 

 

기본적으로 스프링부트 실행 기본 파일인 Application 파일과, 하위 도메인으로 사용할 board와 같은 폴더 (게시글), 프로젝트 전체적으로 또는 각 도메인의 내용 구현에 필요한 부가적인 파일들이 common 폴더에 들어간다. (ex. spring security, kafka, global exception 등) common 폴더에 대한 내용은 추후 업로드 할 예정!

Glim 프로젝트 코드 보러가기 👈

 

 

 

이 중 chatting 폴더의 내부를 보면 위와 같이 총 5개의 폴더와 dto 내부에 2개의 폴더를 추가로 주었음을 볼 수 있다.

그렇다면 해당 폴더들의 역할을 알아보도록 하자.

 

 

1. controller

 

사진과 같이 Controller는 기능을 사용하기 위한 통로이다. 클라이언트 측에서 요청이 들어오면 요청이 들어온 uri를 RequestMapping과 매칭하며 해당 요청의 Method에 따른 Service의  기능을 실행한다. 여기서 Method는 아래와 같이 나뉜다.

GET	데이터 요청
POST	데이터 삽입
PATCH	데이터 일부 수정
PUT	데이터 수정
DELETE	삭제

 

실제 Method는 종류가 더 있지만 보편적으로 많이 사용하는 메서드는 위와 같다. 여기서 PATCH와 PUT은 데이터 수정 요청으로 같으나 보통 일부 수정은 PATCH, 전체적인 수정은 PUT으로 많이 사용한다고 한다. 물론 GET요청에서 수정, 삭제 기능을 만들어 사용해도 정상 작동은 하나, 일관성을 해치기 때문에 요청 메서드에 맞춰 기능을 개발하는 것을 추천한다.

 

 

2. Service

 

Service는 Controller를 통해 실행된 기능의 동작 구간이다. 사진과 같이 Repository를 이용하는 주된 공간이다. 클라이언트 측의 요청에 따른 기능을 실행하고 그에 따른 결과를 리턴하거나 요청 실패 시 에러를 던져주는 역할을 한다.

 

 

3. Repository

 

Repository는 각종 DB 또는 API, Library 등을 통해 가공 또는 생성한 데이터를 서버측에 저장 또는 전송하기 위한 인터페이스이다. 해당 프로젝트에서는 JPA - mysql을 사용하여 구성했다. 여기서 JPA는 Docs에 명시된 규칙을 통해 메서드를 생성하면 자동으로 해당하는 쿼리를 날려 DB와 연동한 작업을 간단히 할 수 있도록 도와준다. 기본적으로 JpaRepository<T, U> 내부에 명시된 도메인의 테이블에서 find, save(insert, update 자동전환), delete 세 가지를 기본으로 응용하여 사용한다. 여기서 T는 도메인(테이블)을 입력하고, U에는 해당 도메인의 Primary Key의 클래스를 입력해준다.

 

 

4. Domain

 

JPA - mysql 기준으로 작성된 기본적인 domain의 설정이다. 실제 연동할 테이블과 정확히 일치하는 Table name과 Column name을 입력해 주어야하며 컬럼의 클래스 또한 맞춰주어야한다.

 

 

5. DTO

  - request

dto는 기본적으로 Domain을 기준으로 각각의 request, response별로 클래스를 생성해준다. request의 경우를 예로 들면 @Id와 같이 auto increase 하는 부분 또는 createdAt과 같이 now()를 사용하는 사용자가 입력하지 않는 부분을 제외한 필요한 데이터만 @RequestBody를 통해 바로 담을 수 있도록 만든 클래스이다. 회원가입이라고 생각하면 아이디, 패스워드, 이름, 성별 등의 많은 데이터를 모두 파라미터를 이용하면 상당히 귀찮고, 단순 HttpRequest와 같은 방식으로 가져온다면 테이블 형식과 맞추는 일을 손수 해주어야한다. 

 

하지만 위와같이 @RequestBody에 해당 domain의 Request를 만들어 받으면

 

해당하는 요청 정보를 @AllArgsConstructor 또는 @Setter를 통해 요청이 들어오면 자동으로 변수를 지정해준다. 추후 toEntity 메서드를 추가하여 JPA를 통해 DB에 저장할때 DB형태에 맞도록 수정하여 누락되는 데이터 없이 저장할 수 있다. (물론 클라이언트 측에서 보내주는 json형태의 body의 key값과 변수명이 일치해야한다.)

 

  - response

response는 request와 비슷하면서 약간의 차이를 보인다. 기본적으로 요청을 통해 나온 결과 값을 return할 때 사용하는데, 굳이 전송하여 보여주지 않아도되는 데이터 또는 연관된 데이터를 한 번에 보낼 수 있도록 만든 틀이라고 생각하면된다. Model 객체를 이용하거나 Map을 통해 직접 설정하여 보내주어도 되지만 매번 귀찮기 때문에 따로 만든다고 보면 편하다. 

 

예로 사진과 같이 새로운 채팅방을 만들어 생성된 채팅방의 정보와, 채팅방 내부의 이용자 정보를 한번에 보내기 위해 ViewChatRoomResponse를 변도로 만들어 담아 보내주었다.

 

위와 같이 기존의 createdAt이 보이지않고, user, msg, hasRead 등의 부가적인 정보가 한번에 전송될 수 있도록 설정됨을 볼 수 있다.

 

 

요약하면, Client => Controller => Service => Repository => Domain(DB) 형식의 데이터 이동 구조를 가지며, 그림으로 보면 아래와 같다.

 

이번 내용은 본인의 프로젝트에 적용했던 데이터 이동 구조이며, 보다 나은 방법이 있을 수 있음을 명시하자.