패키지 구조는 어떻게 짜는 게 맞을까?

본 글은 글쓴이의 개인적인 생각이 담겨있을 수 있습니다.

꼬리별 프로젝트 - Server Clematis
https://github.com/KKoRiByeol/Clematis

문제

꼬리별 프로젝트의 끝을 달리고 있는 와중에 IDE의 왼쪽을 쳐다보면
수많은 Service 클래스들을 보고 기겁을 하곤 한다.

이번 꼬리별 프로젝트를 진행하면서 Service 클래스에게는 SRP를 엄격하게 적용시켜,
Service를 기능별로 작게 나누는 것이 목표 중 하나로 채택되어 있다.
그래서 Service 클래스가 굉장히 많은 것을 체감하고 있다.

현재 꼬리별 프로젝트는 계층형 패키지 구조를 사용하여 프로젝트를 진행하고 있는데,
이 계층형 패키지 구조를 이용하게 되면 같은 Layer끼리 묶여 있어
이 프로젝트에 대해 알고 있는 사람은 쉽게 볼 수 있지만 (꼭 그런 것은 아닌 것 같다.)
모르는 사람은 파일 하나 찾는데도 많은 시간을 들일 수도 있다.

그래서 요즘엔 도메인형 패키지 구조를 사용하라는 것이 추세인듯 하다.
아직도 계층형과 도메인형 간의 대립이 있지만 거의 도메인형 패키지 구조가 좋다는 추세로 가는 것 같다.

그래서 현재 꼬리별 프로젝트의 패키지 구조를 계층형에서 도메인형으로 변경하고자 한다.

해결

다음은 도메인형 패키지 구조로 변경하기 전의 꼬리별 프로젝트의 패키지 구조이다.

com
 ㄴ dsm
     ㄴ kkoribyeol
         ㄴ configuration
         ㄴ controller
         |   ㄴ request
         |   ㄴ response
         |   ㄴ filter
         ㄴ domain
         ㄴ exception
         |   ㄴ entrypoint
         |   ㄴ handler
         ㄴ repository
         ㄴ service
         |   ㄴ attribute
         |   ㄴ provider
         ㄴ KkoribyeolApplication.kt

글 작성 기준으로 Service 클래스가 19개 있기 때문에
service package를 피는 것만으로도 엄청나게 많은 클래스들이 튀어나온다.

변경된 꼬리별 프로젝트의 패키지 구조이다.

com
 ㄴ dsm
     ㄴ clematis
         ㄴ domain
         |   ㄴ account
         |   |   ㄴ controller
         |   |   |   ㄴ request
         |   |   |   ㄴ response
         |   |   ㄴ service
         |   |   |   ㄴ provider
         |   |   ㄴ repository
         |   ㄴ project
         |   |   ㄴ controller
         |   |   |   ㄴ request
         |   |   |   ㄴ response
         |   |   ㄴ service
         |   |   |   ㄴ provider
         |   |   ㄴ repository
         |   ...
         ㄴ global
             ㄴ configuration
             ㄴ dto
             ㄴ attribute
             ㄴ security
             |   ㄴ configuration
             |   ㄴ filter
             |   ㄴ provider
             ㄴ exception
             |   ㄴ entrypoint
             |   ㄴ handler
             |   ㄴ response
             ㄴ validation

이제 패키지가 도메인 별로 나누어져 있기 때문에
원하는 클래스를 찾기가 쉬워지고 더 명확해졌다.

또한 기존에 Request나 Response 객체를 Controller에서만 다루어야 한다는 것에 대하여
어떻게 해결해야 할지 몰랐는데 이렇게 패키지 구조를 바꾸는 것만으로도 쉽게 해결이 되었다.

기존에는 Request 객체를 Service Layer에 넘기지 않으려 했는데,
그러니 Request 안의 내용을 모두 분해해서 Service에 넘겨야 했고,
만약 Request의 필드가 많다면 메소드의 매개변수도 많아지기 때문에
Clean Code에 적합하지 않다고 생각했다.
.
하지만 도메인형 패키지 구조로 바꾸고 나서는 global.dto 패키지에
정말 값을 전달하기만 하는 객체를 만들어 관리하기가 쉬워졌다.