ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 왜 멀티모듈 프로젝트로 변경하려고 하는가?
    운영 중인 서비스/Coconut. 2024. 4. 26. 14:37

     

    멀티 레포 형태로 프로젝트를 관리하면서 느낀 단점과 멀티모듈 형태로 개선하는 과정을 정리하였습니다.


     

    아래의 글은 다음과 같은 순서로 작성되어있습니다.

    1. 최초에 여러 개의 프로젝트(멀티 프로젝트)를 만든 이유

    2. 멀티 프로젝트에서 발생하는 이슈

    3. 멀티 모듈 프로젝트로 변경

     

     

    1. 최초에 여러 개의 프로젝트(멀티 프로젝트)를 만든 이유

    처음 프로젝트 관리 방법을 고민하면서 멀티 모듈 프로젝트를 염두에 두었으나 최종적으로는 개별 프로젝트로 만드는 방향을 선택하였습니다. 당시에는 아래의 이유로 개별 프로젝트를 여러개 만드는 것을 선택하였습니다.

     

    1. 본인이 추가 하고 싶은 도메인이 있다면 그 부분에 대해서 독립적으로 작업할 수 있도록 만들자.

    2. 하나의 큰 프로젝트를 관리하기 보다는 간결한 작은 프로젝트가 더 유연하지 않을까.

     

     

    2. 멀티 프로젝트에서 발생하는 이슈

    하지만 2번째 서비스를 만들기 시작하자마자 뭔가 잘못되었다는 것을 느꼈습니다.

    왼쪽 이미지는 community 서비스, 오른족 이미지는 퀴즈 서비스입니다. common이라는 폴더의 모양이 상당히 비슷합니다.

    개별 서비스로 운영은 되지만, 여전히 서비스 간에 많은 것들이 공유되어야한다는 것을 뒤늦게 인지하였습니다.

     

     

    이 문제를 해결하려면 2가지 선택이 있을 것 같습니다.

    지금 처럼 멀티 프로젝트의 형태를 유지하려면, 서비스 간에 공유되는 내용을 패키지로 배포하고 저장소에서 다운 받는 형태로 진행이 되어야할 것이고, 아니라면 멀티 모듈 프로젝트로 변경이 필요할 것 같습니다.

     

     

    3. 멀티 모듈 프로젝트로 변경

    별도의 라이브러리를 만들어서 저장소에 관리하는 것 보다 멀티 모듈 프로젝트로 가는 것이 훨씬 효율적일 것이라 보고 멀티 모듈 형태로 변경을 진행합니다.

     

    3-1. quiz 서비스를 sub-module로 만들기

    프로젝트 자체는 퀴즈 서비스에 사용하는 프로젝트를 그대로 쓰되, 퀴즈 서비스의 구현 내용은 sub-module로 변경해줍니다.

     

     

    그리고 build.gradle에서 전역으로 사용될 요소와 퀴즈 서비스에서만 사용될 요소를 분리합니다.

     

     

    3-2. global 모듈 만들기

    common에서 사용되는 것들 중에 다른 서비스들과 공유해야되는 부분이 있다면 루트 프로젝트로 끌어올려줍니다.

    common이란 이름은 이것저것 다 넣어도 될 것 같은 이름이니 global로 변경하는 것이 조금 더 나아보입니다.

     

     

    여러 개의 서비스에서 공통으로 사용될 것으로 보여지는 요소들을 추려냈습니다.

    Gradle에 implement 이후 실행을 해봅니다.

     

     

    RestTemplate을 찾을 수 없다는 에러가 발생하면서 실행이 되지 않습니다.

     

     

    퀴즈 서비스가 실행될 때 com.coconut.quiz_service에서만 컴포넌트 스캔을 진행해서 global에 있는 RestTemplate에 대한 bean을 찾지 못하는 것 같습니다. 퀴즈 서비스의 진입점에서 ComponentScan의 범위를 지정해줍니다.

     

     

    3-3. community service 가져오기

    우선 기존 새로운 community_service 모듈을 생성한 뒤, 필요한 소스 코드들을 가지고 옵니다.

    (왼쪽은 기존 community_spring의 폴더 구조이고, 오른쪽은 멀티 모듈 프로젝트의 일부로 이동된 후의 폴더구조입니다)

     

     

     

    community 서비스에는 queryDsl 설정이 있어서 까다로울 것이라고 생각했지만 수월하게 옮겨졌습니다.

    눈여겨볼 지점은 global에 있는 BaseEntity를 community_service의 queryDsl에서 사용하려면 global에도 queryDsl 설정이 되어야한다는 점입니다.

     

     

     

    4. 정리하기

    CI/CD까지 정리하고 나니 시간이 상당히 걸리는 작업이었습니다. ( CI / CD 반영 )

    전체적으로 공통된 요소는 global 프로젝트로 이동하여 중복을 줄인점은 확실히 커다란 장점인 것 같습니다. 조금 아쉬운 점은 깃 브랜치가 조금 어지러워졌다는 점이 있을 것 같습니다.

     

     

     

     

     

Designed by Tistory.