프로젝트를 진행하며 도메인과 관련된 클래스들이 많아지며 보기 좋은 패키지 구조로 변경해야 된다고 느꼈다.
왜? 계층형 구조로 만들었나?
초반에 프로젝트를 진행하며 구조를 빠르게 파악할 수 있도록 만들었다.
하지만 시간이 흐를수록 클래스가 늘어남에 어떠한 관계가 있는지 패키지만으로 판단하기가 어려웠다..
아래 그림이 현재 패키지 구조인 계층형 구조다.
지금부터 프로젝트를 다시한번 살펴보며 패키지 구조를 변경하여 더 좋은 패키지 구조를 만드는 것이 목표가 될 것이다.
해당 프로젝트의 도메인 패키지는 아래 그림과 같다.
actor, consumer, movie, reservation, screening, seat, ticket 총 7개의 도메인이 존재하고 이에 따른 repository도 추가적으로 7개가 존재한다.
애그러거트 관계의 유무?
여기서 문제점은 각 도메인에 대한 관계는 어떻게 알 수 있느냐에 문제가 발생한다.
필자인 ‘나’ 만 알 수 있는 것이다. 상대방이 나의 코드를 직접 까보지 않는 이상 어떠한 관계가 있는지 알 수 가 없다.
다음으로 컨트롤러와 서비스의 패키지를 살펴보자.
- controller
- service
규모가 커지면 커질수록 클래스들이 많아질것이고 현재는 어떠한 도메인에 서비스인지 한눈에 알아보기 쉽지만 클래스들이 많아지면 하나의 디렉토리에 많은 클래스들이 있어 판단하기 어려울 것이다.
도메인 패키지 구조
도메인 주도 개발과 객체지향 프로그래밍, ORM과 같은 기술을 사용함에 도메인으로로 패키지 하는 것이 더 알맞다고 생각하여 아래와 같이 패키지 구조로 변경하였다.
상영 애그리거트는 movie를 가지고 생성되므로 screening 하위에 movie 패키지를 넣어놨고 controller와 dto, service, domian 패키지를 각각 분리하여 모듈화하였다.
이러한 구조는 계층형 구조로 설계한 것보다 도메인의 관계와 관련된 코드의 응집도도 높일 수 있을 뿐만 아니라 도메인에 대해 이해도도 높아질 것이다.
결론
지금의 경우는 패키지 구조로 관계를 파악하기 어렵고 클래스들이 많아져 직관적으로 무엇이 있는지 판단하기가 어려웠다.
도메인 패키지 구조는 이러한 문제를 해결해준다. 관련된 코드들을 도메인별로 모으고 그 안에 domain, service, controller 3계층으로 나누어 관련된 코드들을 한곳에 모아두고 한 눈에 알아볼 수 있다는 장점이 생겼다.
그리고 기본적으로 팀 프로젝트에선 어떤 패키지 구조를 하느냐에 따라 달라질 것 같고, 둘의 장단점이 존재하므로 간단한 웹서비스 같은 경우는 계층 구조인 패키지로 설계할 것이고 큰 서비스같은 경우는 클래스들이 많아 지므로 도메인 구조로 설계하는 방향이 맞을 것 같다.