[BE] 멀티 모듈 적용

[zeus6768]

발제 동기

문의하기를 개발하고 있었어요.

문의하기 기능에는 member 외에는 다른 도메인이 필요하지 않아요.

우리 서비스의 주요 비즈니스 로직과 무관하기 때문이에요.

관리자 기능에 해당한다는 것이지요.

별도의 관리 대상으로 봐야 한다고 생각했어요.

서로의 테스트에도 영향을 주지 않아야 하구요.

관리자 기능에서는 공통 로직을 추출해낸 ServiceTest, MockMvcTest 와 같은 추상 클래스도 아직 불필요해요.

그래서 다른 모듈로 분리하는 아이디어를 떠올리게 되었어요❗

고려할 점

1. 패키지 구조

현재 도메인 > 계층 구조 순으로 패키지 명명을 하고 있어요.

명확한 네이밍을 강제하기 위해 이런 규칙을 적용하고 있었어요.

디렉토리 깊이가 깊어진다는 단점이 있어요.

AS-IS

$ tree backend/src/main/java/codezap

backend/src/main/java/codezap
├── CodeZapApplication.java
├── template
│   ├── controller
│   │   ├── SpringDocTemplateController.java
│   │   └── TemplateController.java
│   ├── domain
│   │   ├── SourceCode.java
│   │   ├── Template.java
│   │   ├── TemplateTag.java
│   │   ├── Thumbnail.java
│   │   └── Visibility.java
│   ├── dto
│   │   ├── request
│   │   │   ├── CreateSourceCodeRequest.java
│   │   │   ├── (생략)
│   │   │   └── validation
│   │   │       ├── SourceCodesCount.java
│   │   │       └── (생략)
│   │   └── response
│   │       ├── ExploreTemplatesResponse.java
│   │       └── (생략)
│   ├── repository
│   │   ├── FullTextFunctionContributor.java
│   │   ├── (생략)
│   │   └── strategy
│   │       ├── FullTextSearchSearchStrategy.java
│   │       ├── LikeSearchStrategy.java
│   │       └── SearchStrategy.java
│   └── service
│       ├── SourceCodeService.java
│       ├── TemplateService.java
│       ├── ThumbnailService.java
│       └── facade
│           ├── TemplateApplicationService.java
│           └── TemplateOwnershipChecker.java

(생략)

모듈을 분리한다면 꼭 그럴 필요가 있을까요?

더 간결한 패키지 구조를 사용해도 좋을 것 같아요.

아래는 간결해지는 구조를 나타내기 위한 예시일 뿐이라는 점 참고해주세요.

구체적으로 어떤 패키지 구조가 될지는 논의 후 결정해야겠죠?

TO-BE

$ tree backend/app/src/main/java/com/codezap/app

backend/app/src/main/java/com/codezap/app
├── Application.java
├── config
│   ├── DataSourceConfig.java
│   └── DataSourceRouter.java
├── controller
│   ├── AuthController.java
│   ├── CategoryController.java
│   ├── LikesController.java
│   ├── MemberController.java
│   ├── TagController.java
│   └── TemplateController.java
└── service
    ├── AuthService.java
    ├── CategoryService.java
    ├── LikedChecker.java
    ├── LikesService.java
    ├── MemberService.java
    ├── SourceCodeService.java
    ├── TagService.java
    ├── TemplateApplicationService.java
    ├── TemplateOwnershipChecker.java
    ├── TemplateService.java
    └── ThumbnailService.java

2. 모듈 간 의존성

모듈 간 의존성 역시 단방향이어야 해요.

MVC 미션을 떠올려보면 알 수 있어요.

app 모듈에서 mvc 모듈을 의존해요.

mvc 모듈이 app 모듈에 의존하면 상호 참조 문제가 있겠죠?

3. 모듈 간 통신

모듈 간 통신은 인터페이스를 통해 이루어져야 해요.

구현이 변하더라도 사용하는 쪽에 영향을 미치면 안 되니까요.

4. 모듈 분리 전략 🚨🚨🚨

코드잽에 맞는 모듈 분리 전략을 함께 논의해봐요. 저는 다음과 같이 고민해봤어요.

전략 1: 공통 기능을 모아놓은 모듈과, 도메인별 모듈로 분리

• template: 코드잽의 핵심 도메인. 템플릿, 소스코드, 카테고리, 태그 등
• member: 회원 정보
• auth: 인증 및 인가, OAuth
• admin: 관리자 기능. 문의하기, 회원 임시비밀번호 발급, 글 삭제 등.
• commons: 공통 로직. 전역 예외 처리, 에러 코드, 로깅, 직렬화 & 역직렬화, 검증, JPA Auditing

장점

도메인별로 분리했기 때문에, 기존 작업 방식에서 크게 달라지지 않아요.

도메인별 패키지가 모듈이 되었을 뿐이거든요.

그래서 새로운 모듈 및 패키지 구조에 적응하는 데 걸리는 시간이 적을 것 같아요.

단점

template 모듈은 여전히 복잡하고 뚱뚱할거에요.

전략 2: Layered Architecture에 따른 분리

• Presentation Layer
  • web: 컨트롤러, Argument Resolver, 필터
• Business Layer
  • service: 서비스
  • domain: 도메인
• Persistence Layer: DB, Cache 등
  • persistence: 레포지토리, 캐시, 엔티티, DataSource, QueryDSL
• External: 외부 의존성. Http client 통신 등

장점

계층별로 모듈을 분리함으로써 중복된 코드가 제거되고 객체 간 역할이 뚜렷해져요.

장기적으로 보면 유지보수에 더 좋다고 생각해요.

단점

🚨 도메인과 엔티티를 분리해야 할 것 같아요.

Persistence 계층과 도메인 계층의 의존성 때문인데요.

현재는 @Entity 애너테이션 및 그와 관련된 설정 탓에 도메인 계층이 Persistence 계층과 강하게 결합되어있는 상태에요.

모듈 간 의존성이 단방향이어야 해서, 도메인을 엔티티와 분리해야 해요.

분리하지 않고도 좋은 구조를 만들 수 있다면 그렇게 하고 싶어요 😭

5. 프로젝트 그룹에 따른 패키지 명명

웹 사이트 주소의 역순으로 하는 게 컨벤션이에요.

현재 우리는 컨벤션을 따르고 있지는 않아요 😅

groupid, artifactid가 컨벤션이 개발에 큰 영향을 미치지 않았어서 지금까지는 괜찮았어요.

그런데 모듈을 분리한다면, 패키지명에 통일성이 있어야 할 것 같아요.

그래서 다음과 같이 변경하면 되겠다고 생각해봤어요.

AS-IS

• 그룹명: woowacourse
• 루트 패키지명: codezap

TO-BE

• 그룹명: com.codezap
• 루트 패키지명 예시
  • presentation 모듈: com.codezap.web
  • template 모듈: com.codezap.template

참고 자료

Gradle 멀티 프로젝트 관리 | 기억보단 기록을
스프링 부트 단일 모듈 코드에 멀티 모듈을 적용하여 프로젝트 구조 개선하기 | velog

[zeus6768]

2024.11.13(수) 회의 결과

점진적으로 모듈 분리를 진행하기로 결정했습니다.

Global 패키지부터 시작합니다.