목차
- 패키지 구조별 장단점 요약
- 나의 경험을 바탕으로 패키지 구조에 대한 생각 정리
- 참고 자료
패키지 구조는 어떻게 가져가는 것이 좋을까?에 대해서 걸어둔 링크의 글을 먼저 확인해보고, 이 글을 읽으면 더 도움이 되리라 생각한다.
우선, 저 글을 요약해보자면 패키지 구조를 구성할 때에는 다음과 같은 두 가지 안이 대표적으로 존재한다. 우선, 두가지 안에 대해 SLIPP글에서 말한 장단점을 요약해보고, 내가 경험한 바를 마지막에 작성하겠다.
1안 - layer 우선
장점
- 도메인 모델 위주 개발에 적합하다.
- 패키지간 중복 코드 발생 가능성이 적어진다.
단점
- 모듈 단위로 분리 시 어려움이 있다.
2안 - 모듈 우선
장점
- 모듈 단위로 분리할 때 유리하다.
단점
- 각 패키지간 순환 참조가 발생할 가능성이 높다.
- 각 모듈 간 중복 코드 발생할 확률이 높다.
- 도메인 간의 관계보다는, 모듈별로 각자 구현할 가능성이 높다.
패키지 구조에 대한 내 경험
우선, 나는 개발 초기에는 주로 2안을 사용했다. 그 이유는, 규모가 작은 프로그램을 만들었기 때문에 도메인간의 관계가 적었고 도메인 패키지 내에도 application/domain/ui/repository 등의 비교적 적은 레이어만 존재했기 때문이다. 하지만 프로젝트를 진행하고 도메인간의 연관관계가 뚜렷해지면서, 1안으로 변경했다.
그 이유는, 우선 도메인 간의 연관관계가 뚜렷할 때 2안의 경우 "이 도메인은 어느 패키지에 넣어야하지?"라는 고민이 생기게 된다. 그리고 혼자 개발하는 것이 아니기 때문에 각 개발자의 성향에 따라 위 질문에 대한 답을 다르게 내려, 내 예상과 다른 패키지에 존재하는 경우 매번 그 파일을 찾는 것이 매우 불편하다. (모든 패키지를 다 열어보아야한 적도 있었다.) 그리고, 위 질문을 한다는 것 자체가 패키지간 순환 참조가 발생할 가능성을 제공한다고 생각한다. 같은 패키지 내부에 있어도 되는 파일인데도 불구하고 모듈별로 구분되어있기 때문에 다른 패키지에 존재하게 되고, 서로를 참조할 수 있기 때문이다.
그래서, 1안을 이용해 레이어별로 패키지를 구성하는 방향으로 변경함으로서 이 문제를 해결할 수 있었다. 또다른 방법으로는 2안에 DDD의 어그리게이트를 적용하는 것도 방법일 것 같다. 어그리게이트 단위로 패키지를 구성하면 관련된 도메인끼리 모을 수 있을 것이다. (실제로 이 방법도 지금 경험하고 있는데, 확실히 2안 또는 2안 + 어그리게이트를 사용하면 2안의 단점인 도메인 간의 관계보다는, 모듈별로 각자 구현할 가능성이 높다. 를 많이 느끼는 것 같다. )
결론적으로 내 선택은!! 1안!
참고 자료
https://www.inflearn.com/questions/16046
https://www.slipp.net/questions/36