📦 레이어 우선
io.github.hyeon9mak.domain.modulename
io.github.hyeon9mak.dao.modulename
io.github.hyeon9mak.service.modulename
io.github.hyeon9mak.web.modulename
장점
- 도메인 모델 위주 개발에 적합하다.
- 각 패키지간의 순환 참조가 발생할 가능성이 적어진다.
- 중복 코드가 거의 발생하지 않는다.
단점
- 추후 모듈 단위로 분리할 때 어려움이 있다.
📦 모듈 우선
io.github.hyeon9mak.modulename.domain
io.github.hyeon9mak.modulename.dao
io.github.hyeon9mak.modulename.service
io.github.hyeon9mak.modulename.web
장점
- 모듈 단위로 분리할 때 유리하다. (주로 모듈 단위로 기능을 이식할 때 유리하다.)
단점
- 각 패키지간 순환 참조가 발생할 가능성이 높다.
(패키지 간 거리가 멀어 눈에 잘 보이지 않는다.) - 각 모듈에 중복된 코드가 발생할 가능성이 높다.
(중복 코드를 최소화 할 경우 순환 참조에 빠질 가능성이 높다.) - 도메인 간의 관계보다 각 모듈별로 각자 구현할 가능성이 높다.
(순환 참조는 회피할 수 있지만, 중복 코드가 수 없이 발생한다.)
📦 개인적으로…
개인적으로 개발 및 설계를 진행하는 입장에서 레이어를 우선하는 패키지 구조가 중복 코드도 적게 발생하고, 순환 참조가 발생하는지 계속 의식할 수 있어서 편리했다. 그러나 완성된 프로젝트 모듈을 다른 프로젝트로 이식하는 과정에서는 굉장한 수모를 겪었고, 모듈을 우선하는 패키지 구조를 다시 바라보게 되었다.
아래는 패키지 구조에 대해 리뷰어 재연링께 질문 드리고 답변 받았던 내용.
Q.
현재 프로젝트의 패키지가 비대한 것 같다는 느낌을 받아서 멤버, 인증 관련 패키지와 지하철 서비스 패키지를 2가지로 나누어보았습니다. 이 과정에서 공통으로 사용될 수 있는 Exception 관리나, 하나의 Advice로 전역적인 Exception 관리를 위해 패키지가 상위레벨로 올라왔구요.나누면서 생각해본 장점으로는 “멤버(인증) 관련 기능만 따로 재사용하거나, 멤버(인증) 기능이 필요없는 지하철 서비스만 따로 사용할 수 있다” 가 떠오르는데, 현업에선 무엇을 기준으로 어떻게 나누는지, 단점은 어떤것들이 있는지 궁금합니다!
또, Exception 패키지가 상위 레벨로 올라온 것을 어떻게 생각하시는지 궁금합니다! 멤버(인증) 패키지와 지하철 서비스 패키지가 각각 가지고 있는게 나았을까요?…
A.
리뷰를 하다보면 개발에 정답이 없다! 라는 말을 많이 하는데 패키지에 대한 부분은 정말 정답이 없는 것 같습니다..!큰 개념으로 계층형과 도메인 형태로 나뉜다! 라는 기준은 어느정도 잡혀있지만, 세부적인 패키지 구조를 나누는 것은 회사/팀/프로젝트 마다 다르기 때문에 경우가 너무 많아 딱 떨어지게 말씀드리기가 힘드네요 ㅎㅎ
제 스타일을 간단하게 말씀드리자면, 먼저 저는 도메인형 구조를 따르며 공통되는 부분만 따로 분리하는 편이고, 인증과 같이 공통되는 부분을 인터페이스로 분리 후 도메인에 맞게 구현체를 만드는 방식을 선호하긴 합니다!
정답이 없다! 라는 뜻은 어떠한 상황에선 장점인 부분이 단점이 될 수 있고 단점이였던 부분이 장점이 될 수 있기 때문일텐데요 가장 대표적인 케이스는 재활용성 <-> 응집도 를 두고 트레이드 오프한다고 생각하시면 됩니다 ㅎㅎ
결국 자바 패키지 구조에 정답은 없는거 같다. 더 많이 경험해보고, 내 팀이 해당 패키지 구조를 원하는 이유에 대해 자연스럽게 이해할 수 있는 사람이 되자.
댓글남기기