최근 두 개의 프로젝트를 진행하면서 하나는 계층형 패키지 구조를 다른 하나는 도메인형 패키지 구조를 사용하여 개발하였다.
그러면서 자연스럽게 두 패키지 구조에 대해서 고민하게 되었다.
따라서 프로젝트를 진행하면서 두 패키지 구조에 대한 개인적인 생각을 나열하려고 한다.
도메인 패키지 구조
각 도메인에 따라 패키지를 만들고, 내부에 Controller, Service, Repository, Dto 패키지를 만든다.
- 관련된 코드들이 응집해 있는 장점이 있어 어떤 기능을 구현하려고 할 때, 쉽게 코드를 찾을 수 있다.
- 기능별로 구현을 할 때, 한 패키지 내에서 Controller, Service, Repository를 작성하기 때문에 별도의 패키지 이동 없이 구현이 가능하다.
- 전체적인 구조를 파악할 때, 도메인의 갯수가 많다면 패키지의 갯수가 많아지기 때문에 어려울 수 있다.
- exception이나 dto 등 각 도메인에서 필요한 코드를 같은 패키지에서 관리할 수 있다.
계층형 패키지 구조
Controller, Service, Repository를 각각 패키지를 만들고, 내부에 도메인에 따른 패키지 구성 후 파일을 생성한다.
- 전체적인 구조가 깔끔해서 파악하기 쉽다.
- 각 패키지 내의 파일이 너무 많아질 수 있다.
- 한 기능을 구현할 때, 여러 패키지를 옮겨가며 파일을 만들고 작성해야하기 때문에 번거로움이 있다.
- 서비스의 크기가 크지 않다면, service.member.memberService 와 같이 각 패키지내에 한개의 파일만 존재할 가능성이 높다. 따라서 패키지가 불필요하다고 생각할 수 있다.
다음과 같은 고민을 하였을 때, 아직까지는 도메인 패키지 구조가 협업하기에도 적절하고, 기능을 구현함에 있어도 더 편리한 장점이 있어 앞으로는 계층형 패키지구조보다는 도메인 패키지 구조를 사용하지 않을까 싶다.!!
전체적인 고민
- 다른 도메인의 Service 기능이 필요로 할 때, 아래의 경우 중 어떤 규칙을 세워 구현해야할 지에 대한 고민
- Controller에서 여러 Service를 의존해야하는지
- Service에서 여러 Service를 의존해야하는지
아직까지 해당 부분에 대해서는 정답을 모르겠다. 같이 공부하는 동기나 선배에게 물어보아도 정확한 정답은 없는 것 같다. 개발하는 사람의 스타일마다 달라질 거 같다. 저는 전자보다는 후자를 선호하는 편이다.
Controller 계층은 요청을 받아 파라미터를 검증하고 어떻게 처리하고 어떻게 응답할지 결정하는 계층이기 때문에, 여러 Service에 의존하는 것보다는 하나의 Service에만 의존하고, 의존하는 Service가 비즈니스 로직을 수행하기 위해 필요한 Service들을 의존하는 것이 나은 방법이라고 생각한다.
따라서 해당 패키지 구조가 좋아보인다.
우선 크게 domain, global, infra, web으로 패키지가 나누어져 있다.
- domain 패키지에서는 도메인 별로 패키지를 구성하고 그 내부에는 해당 도메인에 대한 service와 repository만 존재한다. controller는 존재하지 않는다.
- web 패키지는 기능 별로 패키지를 구성한 것 처럼 보인다. 그리고 각각의 기능별 패키지안에는 controller와 service만을 가지고 있다. repository는 존재하지 않는다.
- web 패키지 내의 controller는 같은 패키지 내의 service만을 의존하고, 그 service는 기능을 수행하기 위해 필요한 도메인에 대한 service 들을 의존한다.
아직 위의 패키지 구조로 프로젝트를 개발해본 적은 없지만 추후에 현재 프로젝트를 리펙토링하거나, 새로운 프로젝트에 적용해 볼 예정이다.!!!!
