프로젝트 패키지 구조에 대한 고찰
•
계층형 구조
project┗ contoller
contoller┗ dao
dao┗ domain
domain┗ service
service┗ . . .
. . .계층형 구조는 왼쪽과 같이 각 계층을 대표하는 디렉토리를 기준으로 구성되어 있는 구조를 말합니다. 하지만 디렉토리 안에 많은 클래스들이 모인다는 단점이 있습니다.
•
도메인형 구조
member┗ contoller
contoller┗ domain
domain┗ repository
repository┗ service
service profile┗ contoller
contoller┗ domain
domain┗ repository
repository┗ service
service도메인형 구조는 왼쪽과 같이 도메인 디렉토리를 기준으로 구성이 되어있습니다. 도메인 관련된 코드들이 한데 모여있어 계층형 구조의 단점을 상쇄할 수 있지만 프로젝트의 규모가 작은경우에는 오히려 계층형 구조를 선택하는 것이 좋습니다.
그래서 어떤 구조를 쓰는것이 우리 프로젝트에 좋을까?
스프링 프로젝트를 처음 해보기 때문에, 각 계층에 대한 이해도를 높이는 데에는 계층형 구조가 좋을것 같다는 생각이 듭니다.
하지만 프로젝트 설계단계에서 아래와 같이 큰 기능을 토대로 세부기능을 설계 하였다는 점과 직관적으로 프로젝트를 관리할 수 있다는 점, 추후 신규기능 확장을 고려하면 도메인형 구조가 더 적합하다는 판단이 들었습니다.
결론
조원들과 상의했을 때 프로젝트 규모가 작아서 계층형 구조를 사용하는 것이 더 나을수도 있다는 의견도 있었지만, 위에서 생각했던 내용을 토대로 우리 프로젝트에 왜 도메인형 구조를 써야하는지에 대해 설명했고, 조원들을 설득할 수 있었습니다.
결과
구조에 대한 토대는 아래 블로그를 참고하여 만들었습니다. 큰 기능을 이미 짜놨기 때문에 도메인을 나누는 것에는 무리가 없지만 config 같은 파일 관리에 대해 문제가 생길 것 같아 한 곳을 선택하였습니다.
•
프로젝트 초반
src
┣ main
┃ ┣ java
┃ ┃ ┗ mult
┃ ┃ ┃ ┗ second
┃ ┃ ┃ ┃ ┗ project
┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┣ board
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┃ ┣ gallery
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┃ ┣ member
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┃ ┣ message
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┃ ┣ planner
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┃ ┣ profile
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ domain
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ dto
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┣ repository
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ service
┃ ┃ ┃ ┃ ┃ ┣ global
┃ ┃ ┃ ┃ ┃ ┃ ┣ common
┃ ┃ ┃ ┃ ┃ ┃ ┣ config
┃ ┃ ┃ ┃ ┃ ┃ ┣ error
┃ ┃ ┃ ┃ ┃ ┃ ┣ infra
┃ ┃ ┃ ┃ ┃ ┃ ┣ security
┃ ┃ ┃ ┃ ┃ ┃ ┗ util
┃ ┃ ┃ ┃ ┃ ┗ ProjectApplication.java
┃ ┗ resources•
프로젝트 끝난 직후
infra → global 수정 해야함(만들고 나서 확인함)
)