[Spring] 패키지 구조(계층형, 도메인형)

 예전에 개발했던 서비스를 리팩토링 하던 중 프로젝트의 구조를 정리할 필요성을 느꼈다. 백엔드 부분을 혼자 개발하다보니 패키지 구조에 대해 많이 신경쓰지 않아 이런 문제가 발생한 것 같다. 다른 분들은 어떻게 하고 계신지 조사해본 결과 크게 두가지로 패키지 구조가 나눠진 것을 알 수 있었다.

 

계층형

 

기존에 서비스를 개발할 때 사용하던 구조이다. 서비스 계층에 따라 패키지를 설계하는 방식이다.

장점

• 서비스에 대한 이해가 없더라도 전체적인 구조를 파악하기 쉽다.
• 중복된 코드가 발생할 가능성이 적다.

단점

• 특정 기능을 수정하려고 하면 모든 계층에 그와 관련된 코드가 있어서 수정하기 어렵다.
• Github이나 여러 툴들을 사용해 협업시 개발자들 사이에서 merge conflict가 날수도 있다.

 

도메인형

 

리팩토링 후의 구조이다. config, securtiy, util 과 같이 서비스 전반에 사용되는 패키지들은 commons로 빼서 정리하였다.

사실 도메인 별로 정리를 해도 그 후 layer 별로 패키지가 나뉘게 된다. 패키지 구조 설계상에는 큰 차이는 없지만 실제 작업을 하면서 많은 도움을 받았다. 특히 오래 전 작업한 코드를 리팩토링 할 경우 더욱 쉽게 코드를 파악할 수 있었다.

장점

• 원하는 클래스를 찾기 쉽다.
• 코드의 응집도가 높아집니다.

단점

• 개발자의 설계 취향에 따라 구조가 많이 달라지기도 한다.
• 다른 패키지에 있는 Class 들을 서로 참조하여 순환참조가 발생할 수 있다.

 

 

 처음 개발을 할 당시에는 프로젝트의 구조를 잡고 기능 개발에 힘을 쏟았기에 계층형 구조를 택해도 문제가 없었다. 하지만 복잡도가 높아지고 모듈간의 분리가 명확했기에 도메인형 계층으로 바꾸는 것이 적합하다고 판단하였다. 예전에는 계층형 구조가 많이 보였지만 현재는 도메인형 계층을 가진 서비스가 많아지는 추세인 것 같다.  기존의 계층형 구조를 도메인형 계층으로 바꾸는 노력 또한 많이 보인다. 

 

Reference

https://hyeran-story.tistory.com/160

https://www.geeksforgeeks.org/spring-boot-code-structure/