계층형 구조
기본적인 서비스 계층에 따라 패키지를 설계하는 방식이다.
- config: DI를 위해서 만들어진 패키지
- controller: MVC패턴의 Controller로, 클라이언트의 요청을 적재적소에 뿌려주기 위한 패키지
- domain: 여러 도메인 모델을 담는 패키지
- exception: 예외 처리를 위한 패키지
- repository: 일반적 웹 구조(controller, service, repository)에서 repository로 db와 상호작용하는 역할을 위한 패키지
- security: 보안 처리를 위한 패키지
- util: 여러 유용한 클래스를 담기 위한 패키지
- service: 일반적 웹 구조(controller, service, repository)에서 service로 실제 비즈니스 로직을 담기위한 패키지
장점:
1. 일반적인 구조를 따르고 있어 전체적인 구조를 파악하기 쉽다.
2. 중복 코드 발생 가능성이 적다
3. 계층별 응집도가 높다-> 특정 계층만 보고 싶을때 해당 패키지 선택하면 됨
4. 작은 규모의 프로젝트에서 효과적(패키지에 클래스가 많지 않아 구분하기 쉽고, 구조 자체가 단순하기 때문)
단점:
1. 도메인별 응집도가 낮음-> 도메인의 흐름 파악하기 힘들다(특정 도메인의 흐름을 보려면 모든 계층의 패키지 까봐야함/ 한 패키지에 여러 도메인이 섞여있어 구분하기 힘들다)
2. 특정 도메인의 변경이 발생하면 관련된 모든 계층 패키지 뒤져서 변경해줘야함
3. 규모가 커지면 한 눈에 알아보기 힘들다.(service패키지에 ProductService, UserService, XService등 많아지는 것을 상상해보자)
도메인형 구조
도메인을 기준으로 패키지를 나누는 구조로 다음과 같다.
장점:
1. 원하는 클래스를 찾기가 쉽다.
2. 도메인별 응집도가 높기에 도메인 흐름 파악이 쉬움(특정 도메인 흐름 보려면 특정 패키지만 보면 됨)
3. 특정 도메인의 변경이 발생해도 해당 패키지만 변경이 일어남
4. 큰 규모의 프로젝트에서 효과적(도메인 별로 묶여있기 때문에 계층형 구조와 다르게 클래스가 섞여있지 않아 구분하기 쉽다)
단점:
1. 개발자마다 어느 패키지에 둘지 애매한 클래스들 발생한다.
2. 자신이 예상하는 패키지와 다르면 해당 클래스를 찾기가 어려움
그럼 무슨 패키지 구조가 좋은데?
해당 질문에 정답은 없는 것 같다. 이 둘은 trade-off관계이기 때문이다. 따라서 프로젝트의 성격으로 알맞는 패키지 구조를 설정해야한다.
이번에 진행할 프로젝트는 처음에는 단순한 구조이기 때문에 계층형 구조를 사용해도 좋지만, 점점 ver1, ver2.. etc처럼 확장하면서 커질 예정이므로 계층형 구조를 사용하다 복잡해져서 골머리가 썩는 것 보다는, 처음부터 도메인형 구조를 취해서 확장성을 고려하는 것이 좋아보인다.
Reference
https://ksh-coding.tistory.com/96
https://mson-it.tistory.com/2
