본 글은 글쓴이의 개인적인 생각이 담겨있을 수 있습니다.
꼬리별 프로젝트 - 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
패키지에
정말 값을 전달하기만 하는 객체를 만들어 관리하기가 쉬워졌다.
항상 Spring 으로 서비스를 제작할떄마다 계층형으로 짰는데 domain 형으로 짜는것도 global 과 domain 간의 구분만 잘되면 좋을거같네요!! 좋은글 잘 읽고갑니다 ㅎㅎ