Spring Boot Folder Structure (Best Practices)
Medium
🕊️ 스프링 부트 폴더 구조 모범 사례
개발자들은 코드의 유지보수성, 팀원 간 협업 및 전체 개발 프로세스 개선을 위해 잘 구조화된 폴더 구조를 사용합니다. 스프링 부트 폴더 구조가 중요한 이유는 다음과 같습니다.
- 명확성 및 구성
- 모듈화
- 확장성
- 코드 재사용성
다음은 스프링 부트 애플리케이션에 대한 폴더 구조를 보여줍니다. (링크 참조)
📌 config
애플리케이션 설정을 구성하는 구성 클래스 또는 애플리케이션-레벨의 AppConfig를 포함합니다.
📌 controller
RESTful 컨트롤러 클래스를 포함합니다. 이 클래스는 들어오는 HTTP 요청을 처리하고 API Endpoint를 정의합니다.
📌 DTO
응용 프로그램의 다른 계층 또는 구성 요소 간에 데이터를 전송하기 위해 사용됩니다.
- 비즈니스 로직이 포함되지 않음
- 데이터 운반이 주 목적
📌 Enums
Enum 클래스의 예시로는 SUCCESS, FAIL, PENDING등의 상태가 있습니다.
📌 model
도메인의 구조나 동작을 나타내는 데이터 모델 또는 엔티티를 저장합니다. 데이터베이스 테이블에 매핑되고 데이터의 속성과 관계를 정의합니다.
📌 repository
데이터 접근을 다루는 레파지토리 클래스를 포함합니다. 이러한 클래스는 일반적으로 ORM, JPA 등을 사용하여 데이터베이스와 상호작용 합니다.
📌 service
비즈니스 로직을 구현하는 서비스 클래스를 포함합니다.
📌 utils
코드베이스를 체계적이고 모듈식으로 운영하기 위해 유틸리티 클래스를 배치합니다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2023년 9월 12일 오전 10:06
댓글 6
원문글 내용에 동의하지 않아서, 원문글 댓글을 읽어보니 공감하는 내용 중 한가지가 있어 공유합니다 ㆍ패키지명은 소문자여야 한다
이렇게 하면 프로젝트의 도메인이 무엇인지, 프로젝트에서 무슨 비즈니스를 처리하는지를 알 수가 없어서 동의하기 어려운 거 같습니다. 클린 코드, 클린 아키텍처 둘 중 하나에서 디렉토리들이 소리를 질러야 한다고 말했던 거 같아요. 어떤 도메인인지 무슨 비즈니스를 처리하는지를 바로 알 수 있게요.
최상단에 도메인 클래스를 정의 하고 하위에 controller, dto, model, repository, service 단위로 묶어서 폴더 구조를 잡는건 어떤가요? ex) user[도메인] > controller, dto, model, repository, service
도메인을 파악하기 어렵다는 피드백이 많은데, 저희는 기본 구조를 저렇게 가되 서브도메인 별로 모듈을 구분해 뒀습니다. 불가피하게 모듈 안에서도 도메인 구분이 필요한 경우 controller, service, dto 등을 하위 패키지로 갖는 상위의 도메인 패키지를 나둬 파악할 수 있도록 하면 큰 문제는 없다고 생각합니다. 오히려 한 모듈에 다양한 도메인이 존재하여, 저런 구조일 때 도메인 구별이 안되는게 더 큰 문제가 아닐까 합니다.
utils 라는게 생기면 깊은 고민없이 애매하면 하위로 생성되는 경우가 발생하는데 최대한 utils를 안만드는 방식을 생각하실까요? 활용하는걸까요?
