jigumulmi/
├── admin/
│ ├── src/
│ │ ├── main/
│ │ ├── test/
│ ├── build.gradle
├── core/
│ ├── src/
│ │ ├── main/
│ │ ├── test/
│ │ ├── testFixtures/
│ ├── build.gradle
├── monitor/
├── build.gradle
├── gradle.properties
├── settings.gradle

모듈 의존관계
src/
├── main/
│ └── java/com/jigumulmi/
│ ├── admin/
│ │ ├── banner/
│ │ ├── member/
│ │ └── place/
│ ├── aws/
│ ├── banner/
│ ├── common/
│ ├── config/
│ ├── member/
│ ├── place/
│ └── JigumulmiApplication.java
│ └── resources/
└── test/
└── java/com/jigumulmi/
├── admin/
│ ├── banner/
│ └── place/
├── common/
├── config/security/
├── member/
├── place/
└── resources/
<aside> ⚙
사용자 기능을 담당하는 core와 관리자 기능을 담당하는 admin 모듈로 분리할 때, 격리 수준을 어느 정도로 할 것인지
</aside>
JPA Entity → DTO 변환 작업 로직을 admin 모듈에도 전부 재작성이 필요하여 보류<aside> ⚙
core 모듈 내에서 api, domain, storage 등 모듈 격리 여부
</aside>
모듈 분리의 이점
.properties 등의 설정 파일도 모듈별로 관리→ 기능별 응집도를 높여 유연성, 유지 보수성 향상
학습 차원에서 시도하는 것도 괜찮아 보였지만, admin과 core 분리로도 충분한 실습이 될 것으로 판단
프로젝트의 규모나 성숙도가 세부 모듈을 구분할 정도로 충분히 크지 않아 보류
<aside> 💡
멀티모듈 구조는 루트 모듈 안에 서브 모듈들이 존재하는 형태이다
</aside>
plugins {
// 루트에 적용할 플러그인 지정
id 'java'
id 'org.springframework.boot' apply false
id 'io.spring.dependency-management' apply false
}
java {
// java 플러그인 설정 (버전 등)
sourceCompatibility = project.findProperty("javaVersion")
}
allprojects {
// 루트 모듈 포함 모든 모듈의 공통 설정
// 프로젝트 그룹명, 버전 등
group = project.findProperty("projectGroup")
version = project.findProperty("applicationVersion") + '-SNAPSHOT'
repositories {
mavenCentral()
}
}
subprojects {
// 루트 모듈 제외 서브 모듈들의 공통 설정
// 플로그인, 의존성, 태스크 등
}
pluginManagement { // 공통 플러그인 버전 관리 (gradle.properties 활용)
plugins {
id 'org.springframework.boot' version "${springBootVersion}"
id 'io.spring.dependency-management' version "${springDependencyManagementVersion}"
}
}
rootProject.name = 'jigumulmi'
// 서브 모듈 등록
include(
"core",
"admin"
)
// 공통 설정값 응집
// .gradle 파일에서 사용
applicationVersion=0.0.1
projectGroup=com.jigumulmi
javaVersion=21
springBootVersion=3.2.4
springDependencyManagementVersion=1.1.4
build.gradle에서 플러그인, 의존성, 태스크 등의 추가 설정 가능