문제
프로젝트를 진행하던 와중에 IDE의 왼쪽을 쳐다보면 수많은 Service 클래스들을 보고 기겁을 하곤 한다.
프로젝트에서는 Service 클래스에게는 SRP를 엄격하게 적용시켜 Service를 기능별로 작게 나누는 것이
목표 중 하나이다.
그래서 Service 클래스가 굉장히 많은 것을 확인할 수 있다.
요즘은 도메인형 패키지 구조를 사용하라는 것이 추세인듯 하다.
아직 계층형과 도메인형간의 대립이 있지만 거의 도메인형 패키지 구조가 좋다는 추세로 가는 것 같다.
해결
다음은 도메인형 패키지 구조로 변경하기 전의 어떤 프로젝트의 패키지 구조이다.
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 패키지에
정말 값을 전달하기만 하는 객체를 만들어 관리하기가 쉬워졌다.
참조
'개발 Tip' 카테고리의 다른 글
[개발] 테스트 코드란? (0) | 2023.06.26 |
---|---|
개발용어 모음집 (0) | 2023.03.05 |