스프링 MVC 프로젝트를 다루다보면, 흔히 사용되는 패키지 구조가 있다.
이처럼, 비슷한 성격을 가진 클래스들끼리 모아두는 구조가 흔히 사용되는 방식이다.
규모가 작거나 간단한 프로젝트인 경우는 별다른 무리가 없었지만, 규모가 커질수록 클래스들끼리 얽히는 상황이 종종 발생된다.
그래서 찾아보게 된 패키지 구조 중, 다음과 같이 도메인끼리 분류하는 형식도 존재했다.
이번 프로젝트에서 도메인을 기준으로 패키지를 나눠 협업을 진행하였고, 이에 대한 느낀점을 정리해보려고 한다.
역할 배분이 간단해진다.
팀원이 총 4명이고, 도메인이 8개라면 인당 2개의 도메인을 책임지는 형식으로 진행될 수도 있다.
물론, 도메인마다 구현 난이도는 다르겠지만, 기능을 상세히 나누는 것보단 단순해서 좋았다.
Git 충돌이 덜 일어난다.
각각의 팀원들은 각자의 도메인에만 충실하면 된다. 그래서 다른 팀원과의 코드 충돌이 비교적 덜 일어났다.
git에 익숙하지 않은 팀원이 있다면 정말 좋은 구조라고 생각된다. 그 이유는, 실수로 인한 충돌이 종종 발생할 수 있어서, 그러한 상황을 최대한 줄일 수 있기 때문이다.
그렇다고해서 도메인끼리 분류해놨다고해서 무조건 다른 도메인을 침범하지 말라는 법은 없다. 필요하면 가져다 써야하며 수정할 필요도 있다.
단, 그러한 경우엔 해당 도메인을 책임진 팀원과 미리 소통한다면, 협업하는데 더욱 좋을 것이다.
파일의 위치와 로직의 흐름을 쉽게 파악할 수 있다.
도메인별로 패키지가 분류돼서 로직의 흐름을 파악하는데 훨씬 용이했다.
만약, 기존의 구조를 사용한다면 controller 패키지와 service 패키지 내부에서 사용되는 클래스 파일을 열심히 찾아야할 것이다.
도메인간의 의존성을 쉽게 파악할 수 있다.
필자는 개인적으로 그렇게 느껴졌다.
도메인이 많을 수록 구조가 명확해진다.
개인적으로, 도메인이 최소 4개 이상일 때 이러한 구조를 사용하는 것이 좋아보였다.
도메인의 개수가 3개 이하이거나 규모가 작은 프로젝트라면, 너무 과하게 패키지를 분류한듯한 느낌이 들었다.
사실, 이건 사람마다 느끼는 점이 다를 것 같다.
확장성이 좋다.
새로운 도메인이 추가된다면, 단순히 패키지를 하나 추가하면 된다.
공통 기능을 쉽게 분리해낼 수 있다.
global이나 util패키지처럼, 다른 도메인에서도 쓰이는 로직이 있다면 이를 쉽게 따로 뽑아내서 처리해줄 수 있다.
단, 그만큼 의존성이 높아질테니 충분히 고려한 뒤에 작업하는 것이 좋아보인다.
MSA로 이전하는데 용이할 것이다.
MSA를 직접 다뤄본 적은 없지만, 도메인별로 분리해서 프로젝트 구조를 MSA로 옮긴다면, 쉽게 옮길 수 있을 것 같다는 생각이 들었다.
게다가, 트래픽이 많은 특정 도메인에 한해서 scale-up/out을 용이하게 해줄 수 있을 것 같다.
후기
도메인별로 패키지를 분리하는걸 처음 해봤는데, 단점도 있을거라 생각했지만 압도적으로 많은 장점을 직접 느끼게 돼었다.
앞으로도 도메인의 개수가 많을수록 도메인 기준으로 패키지를 나눠야겠다는 생각이 들었다.
