책에는 별 내용이 없어서 가볍게 Spring 프로젝트의 패키지 구조에 대해 정리해봤습니다.
들어가기 앞서, 김영한님의 의견을 가져왔습니다.
1. 실무에서 프로젝트 구현시 보통 폴더 구조를 어떤식으로 하시나요?
-> 뭔가 약팔이 처럼 실무에서는 이렇게 하는게 정석입니다. 라고 말씀드리면 좋겠지만... 솔직하게 말씀드려서 저는 지금도 프로젝트를 진행할 때 마다 패키지 구조를 고민합니다. 왜냐하면 이 부분은 딱 정해진 정답이 있다기 보다는. 현재 프로젝트의 상황과 규모에 따라서, 거기에 맞는 유지보수하고 확장하기 쉬운 구조가 있기 때문입니다.
예를들어서 블로그 프로젝트가 정말 너무 작아서 단순하게 API 하나를 처리하면 끝난다고 하면, 그냥 패키지 하나에 다 몰아 넣고, 최대한 단순하게 처리하는 것이 좋다 생각합니다.
project
그런데 프로젝트에 요구사항이 추가되면서 기능이 증가하면 이제 컨트롤러, dto, entity, 비즈니스로직을 처리하는 serivce 등으로 패키지를 분할하는게 의미를 가지겠지요.
project
- controller
- dto
- entity
- serivce
여기서 프로젝트가 정말 더 커져서 여러 도메인이 추가되면 도메인 단위로 상위 패키지 개념을 더 추가할 수 있습니다.
예를 들어서 단순히 블로그 API 만 제공하다가, 회원 기능이 추가되면 다음과 같이 될 수 있겠지요.
project
- blog
- controller
- dto
- entity
- service
- member
- controller
- dto
- entity
- service
그런데 이렇게 구성해보니까, 블로그 컨트롤러에서 회원과 관련된 서비스를 자주 사용합니다. 엔티티들도 서로 연관관계가 생깁니다. 그래서 다음과 같은 구조로 변경합니다.
project
- controller
- blog
- member
- service
- blog
- member
- entity
- blog
- member
여기서 더 나아가면 패키지 구조를 넘어서 멀티모듈 프로젝트로 가면서 프로젝트 자체를 여러개로 구성할 수도 있습니다.
제가 이 과정을 통해서 말씀드리고 싶은 진짜 핵심은!
프로젝트가 성장함에 따라 프로젝트 구조도 현재 상황에 맞추어 성장하고 변경할 수 있어야 합니다.
결국 이 부분은 진지한 고민과 학습 그리고 다양한 경험을 통해서 길러질 수 있는 아키텍트의 중요한 기본기라 생각합니다.
com
ㄴ example
ㄴ demo
ㄴ config
ㄴ controller
ㄴ entity
ㄴ repository
ㄴ service
ㄴ exception
스프링 웹 계층의 대표 클래스들을 기반으로 패키징하는 방식이다.
- 전체적인 구조를 빠르게 파악할 수 있지만, 각 패키지에 너무 많은 클래스들이 모이게 된다.
com
ㄴ example
ㄴ demo
ㄴ domain
| ㄴ user
| | ㄴ api
| | ㄴ application
| | ㄴ dao
| | ㄴ domain
| | ㄴ dto
| | ㄴ exception
| ㄴ video
| | ㄴ api
| | ㄴ application
| | ㄴ dao
| | ㄴ domain
| | ㄴ dto
| | ㄴ exception
| ...
ㄴ global
ㄴ auth
ㄴ common
ㄴ config
ㄴ error
ㄴ infra
ㄴ util
스프링 웹 계층에 주목하기보다는 도메인에 주목한다. 각 도메인 별로 패키지를 분리하여 보다 직관적이고, 각 도메인들은 서로를 의존하는 코드가 없도록 설계하기 적합하다.
- 직관적이다.
- 도메인 별로 의존 관계를 줄일 수 있도록 설계하기에 적합하다.
영한님의 조언처럼, 프로젝트마다 적합한 구조가 있기 마련이므로 때마다 잘 선택해서 구성하자!