일전의 django를 이용한 졸업과제 수행 때는 혼자 개발하기도 했고, 기능 구현에만 초점을 두어서 application(기능)별로 쓰이는 것들끼리 때려박아놓는 식의 구조를 만들어냈었다. 구조랍시고 기능별 모듈 구분만 해놓은 게 다였던 나는 현재 진행 중인 마감 할인 플랫폼 앱개발에 있어서, 앞으로의 플랫폼 발전과 팀원과 순조로운 협업 등을 위해 기존의 구조를 바꾸어야하는 상황에 봉착했다.
우리 플랫폼의 경우, 사장님이 사용하시는 사장님 앱과 고객님이 사용하시는 고객님 앱이 따로 존재한다. 현재 우리는 사장님 앱의 기본 기능을 구현해놓은 상태인데, 여기까지는 프로젝트 내에 하나의 모듈에서 controller, service, dto, domain(entity), repository 등을 하위 패키지로 관리하고 있었다. 아래는 기존 프로젝트의 구조를 예를 들어 그린 그림이다.
하지만 이제는 고객님 앱의 구현에 들어감으로써 동시에 접근해야하는 entity 등이 생김으로써 프로젝트 구조를 어떻게 바꿀까라는 고민이 생겼고, 이에 대해 알아보기 시작했다.
멀티모듈 프로젝트
그렇게 찾아보니 많은 사람들이 '멀티모듈'이라는 구조를 사용하는 것을 알게 되었고, 이를 우리 앱 개발에 맞춰 적용하기로 했다. 멀티모듈은 말 그대로 root 모듈 내에 여러 모듈을 두어 관리, 개발하는 구조이다. 보통의 경우 api 모듈, core 모듈, batch 서버 모듈 등으로 나누어 사용하는 것이 많이 보였다. 그 중에서도 내 눈에 띈 건 우아한 형제들 기술 블로그의 글(https://techblog.woowahan.com/2637/)이었다.
이 글에서는 기존에 우리가 spring boot에서의 layer architecture(presentation - service - domain - infrastructure)를 보는 시선과 조금 다르게 해석하여 구조를 설계했는데, 구성요소 각각이 가진 의미를 이용한 정말 좋은 구조였다는 생각이 든다. 구조에 대한 판단과 더불어 각 계층들 간 의존관계 등 많은 것을 깨우치게 해준 글이니 시간이 되는 분들은 읽어보는 것을 추천한다.
여하튼, 내가 생각하고 우리 프로젝트에 적용하게 된 구조에 대해 알아보도록 하겠다. 모듈은 제일 상단 root 모듈, 그 하위에 core, domain, application 모듈로 설계해보았다. 그리고 application 하위에 사장님, 고객님 앱 모듈을 각각 두기로 하였다. 구조를 그림으로 살펴보자면 아래 그림과 같겠다.
이와같은 구조로 변경하며 각 모듈 간의 의존 관계도 정의해보았다. 의존 관계는 아래처럼 정의되었고, 이를 지켜나갈 예정이다.
구조 변경 진행
내가 구조를 바꾸며 가장 애먹었던 부분이 settings.gradle에서의 include 파트, 각 모듈의 의존성 설정이었다. 우선, settings.gradle의 하위에는 root project의 name과 하위 모듈들을 선언해주어야한다. 이는 모듈 생성 시 gradle이 자동으로 include 해주지만, 나의 경우는 원래 존재했던 패키지를 모듈화하기도 했고 위치를 옮기는 등의 작업을 하면서 자동으로 설정되지 않는 부분이 있어 애를 먹었다. 각각의 모듈은 build.gradle을 통해 build 시 필요한 사항을 담고 있으며, root 모듈의 build.gradle에서 공통적인 부분을 설정해준다고 생각하면 편하다.
-
settings.gradle
최종적으로 멀티 모듈화를 끝낸 후의 settings.gradle이다. applicaiont 모듈 내의 사장님(seller), 고객님(customer) 설정을 어떻게 해줘야할지 몰라서 자꾸 build 에러가 났었는데, 블로그들을 뒤지다보니 해당 방법(findProject~ 라인과 바로 윗줄 include 포맷)을 찾을 수 있었다(어느 블로그를 참고했는지 찾기가 힘들어 링크는 걸어주지 못한다...). 다른 방법으로 include가 가능한지는 모르겠다. -
build.gradle
위에서 말했듯 build.gradle은 각 모듈별로 가지고 있으며, 각 모듈별 설정을 해주어야한다. 각 모듈이 필요로하는 의존성 주입을 통해 모듈 별로 필요한 connection만을 하게끔 설계하는 것이 효율적인 process로 가는 길일 것이다. 하지만 모든 모듈이 가지는 의존성은 존재할 것이다. 바로 이를 root 모듈의 build.gradle에서 정의해주면 되는 것이다. root 모듈의 build.gradle에는 이외에도 모듈 간 관계 명시, 단독 실행을 하지 않는 모듈(지금 나의 구조에서는 core, domain)의 라이브러리화 등을 설정해주면 된다.
하위의 모듈에 공통적으로 적용되는 플러그인, 의존성 등 기본 설정을 이 섹션에서 해주면 된다. 나는 우선 멀티 모듈로 바꾸기 전 구조에서 사용했던 build.gradle에 있는 것을 그대로 적용해놨으나, 이후 필요에 따라 수정할 계획이다.
proejct 섹션에서는 각 모듈에 대한 의존성, bootJar, jar 설정 등을 해주면 된다. 위에서 말했듯 core, domain은 단독 실행을 위한 모듈이 아니라 라이브러리같이 사용할 모듈이기 때문에 booJar, jar 설정을 해준 모습이다.이에 관해서는 더할 말이 있는데, 너무 복잡해서 눈치 못챘겠지만 프로젝트 전체 구조 사진을 보면 applicaion.java가 존재하는 모듈은 사장님모듈 하나이다(물론 고객님 모듈도 application.java를 만들고 이를 통해 실행해야 함.).
모듈들의 dependencies 역시 위의 의존성 그림에 맞추어 주입해준 모습이다.
마무리(?)
이렇게 구조를 변경한 후 각각의 모듈의 의미에 집중하고 잘 이용해서 개발을 진행할 예정이다. 다음 글은 구조 변경 후 각 모듈에서의 필요한 설정, 기존 구조에서 달라지며 각 모듈에 접근하는 방식이 변경된 점 등을 정리해볼 것이다.
물론 아직 구조상 부족한 부분이 있다. 본격적으로 프로젝트 구조에 대한 생각을 골똘히 해본 적이 많이 없었는데, 이번 기회를 통해 많은 공부를 한 것 같다. 앞으로도 팀원과 계속적인 상의, 공부를 통해 좋은 구조를 갖춰나가야 할 것이다. 동시에 계속 정리하는 글을 남기며 머리에 새길 생각이다.
