다중모듈 프로젝트 구성
먼저 모듈의 의미를 정의해보면, 모듈이란 ...
- 다른 모듈의 코드와 분리된 코드베이스를 갖는다.
- 빌드 결과물은 개별 아티팩트(JAR 파일)로 변환된다.
- 다른 모듈이나 외부 라이브러리에 대한 의존성을 정의할 수 있다.
다중모듈 프로젝트는 여러 모듈로 구성된 프로젝트로, 각 모듈은 애플리케이션의 개별적인 기능 또는 구성 요소를 의미한다. 다음은 Spring Boot 멀티모듈 프로젝트를 사용할 때의 몇 가지 장점과 단점이다.
■ 장점
- 모듈식 구조: 멀티모듈 프로젝트를 사용하면 우려 사항을 명확하게 분리할 수 있으며 모듈식 구조로 애플리케이션을 유지 관리하고 확장하기가 더 쉬워진다.
- 개선된 구조: 멀티모듈 프로젝트는 코드들이 기능별로 단일 모듈에 그룹화되어 있어 개발자가 코드를 더 쉽게 찾고 수정할 수 있다.
- 재사용 가능성: 멀티모듈 프로젝트의 모듈은 다른 프로젝트에서 재 사용할 수 있으므로 새 애플리케이션을 개발할 때 시간과 노력을 절약할 수 있다.
- 명확한 종속성: 멀티모듈 프로젝트를 사용하면 모듈 간의 종속성을 명확하게 정의할 수 있으므로 복잡성을 관리하고 애플리케이션의 구조가 잘 잡혀 있는지 확인할 수 있다.
■ 단점
- 복잡성 증가: 멀티모듈 프로젝트는 단일 모듈 프로젝트보다 더 복잡할 수 있으므로 이해하고 유지 관리하기가 더 어려울 수 있다. 프로젝트에 많은 모듈이 있는 경우 특히 그렇다.
- 빌드 시간 증가: 멀티모듈 프로젝트는 각 모듈을 개별적으로 빌드해야 하므로 단일 모듈 프로젝트보다 빌드 시간이 더 오래 걸릴 수 있다. Gradle 또는 Maven을 사용하여 빌드 프로세스를 관리하면 이 문제를 완화할 수 있다.
- 설정 시간 증가: 다중모듈 프로젝트를 설정하는 데는 관리해야 할 구성 파일과 빌드 스크립트가 더 많기 때문에 단일 모듈 프로젝트를 설정하는 것보다 시간이 더 오래 걸릴 수 있다.
- 순환 종속성 위험: 멀티모듈 프로젝트에서는 모듈 간에 순환 종속성이 발생할 위험이 있으며, 이로 인해 런타임 오류 및 성능 저하와 같은 문제가 발생할 수 있다. 이 문제를 방지하려면 모듈 간의 종속성에 세심한 주의를 기울여야 한다.
요약하면 Spring Boot 멀티모듈 프로젝트는 모듈성, 재사용성, 명확한 종속성 등 여러 가지 이점을 제공할 수 있지만 복잡성이 증가하고 빌드 시간이 길어질 수 있다는 단점도 있다.
멀티모듈 프로젝트를 구현하기로 결정한 것은 프로젝트 구성을 복잡성을 고려하더라도 명확한 모듈화를 위함이다. 아래 프로젝트는 3개의 멀티모듈로 구성되어 있다.
각 모듈은 Java 소스, build.gradle 파일로 구성된 별도의 폴더에 위치한다.
- 최상위 build.gradle 파일은 모든 하위 모듈 간에 공유되는 빌드 동작을 구성하여 하위 모듈에서 중복할 필요가 없도록 한다.
- studio 모듈에는 실제 Spring Boot 애플리케이션과 컨텍스트 구성을 위한 JavaConfig 이 포함되어 있다.
- architecture-ee 모듈은 JDBC 프로그램밍 및 공통에 해당하는 클래스와 스프링 컨텍스트 구성을 돕는 JavaConfig 클래스를 포함하고 있다.
- architecture-community 웹 모듈은 애플리케이션의 서비스 와 웹 계층을 구현한다.
부모빌드 파일
① 최상위에 위치한 부모빌드에 자식에 해당하는 모듈을 포함 하려면 부모 settings.gradle 파일에 include 키워드를 사용하여 모듈들을 추가한다.
rootProject.name = 'studio-server'
include "architecture-ee"
include "architecture-community"
include "studio"
이제 상위 폴더에서 ./gradlew 빌드를 실행하면 Gradle 은 자동으로 모듈 간 종속성을 해결하고 settings.gradle 에 나열된 순서와 관계없이 (모듈간의 의존성을 파악하여) 올바른 순서로 빌드를 수행한다.
예를 들어, 공통에 해당하는 architecture-ee 모듈은 다른 모든 모듈이 종속되어 있으므로 다른 모든 모듈보다 먼저 빌드된다.
부모 build.gradle 파일에서 모든 하위 모듈에서 공유되는 기본 구성을 정의한다: 이를 통하여 하위 모듈의 설정을 단순화할 수 있다.
데이터베이스 마이그레이션 : Flyway
Flyway 는 데이터베이스 스키마 변경을 관리하기 위해 Spring Boot와 함께 사용할 수 있는 인기 있는 데이터베이스 마이그레이션 도구이다. 다음은 Spring Boot에서 Flyway를 사용할 때의 몇 가지 장점과 단점이다.
■ 장점
- 손쉬운 통합: Flyway는 간단한 구성을 통해 Spring Boot 애플리케이션에 쉽게 통합할 수 있다.
- 버전 관리: Flyway를 사용하면 데이터베이스 스키마 변경 사항을 형상관리와 유시한 버전 제어 방식으로 관리할 수 있으므로 시간 경과에 따른 변경 사항을 쉽게 추적하고 관리할 수 있다.
- 일관된 데이터베이스 상태: Flyway는 프로젝트에 참여하는 개발자 수나 데이터베이스가 배포된 환경에 관계없이 데이터베이스의 모든 인스턴스가 동일한 상태를 유지하도록 돕는다.
- 반복 가능한 마이그레이션: Flyway는 반복 가능한 마이그레이션을 지원하므로 새 열 또는 인덱스 추가와 같은 작업에 사용할 수 있으며, 이러한 변경 사항이 데이터베이스의 모든 인스턴스에 일관되게 적용되도록 보장한다.
- 여러 데이터베이스를 지원: Flyway는 Oracle, MySQL, PostgreSQL, SQL Server 등 다양한 데이터베이스를 지원하므로 데이터베이스 스키마 변경을 관리할 수 있는 다목적 솔루션이다.
■ 단점
- 추가 구성: Flyway를 Spring Boot 애플리케이션에 통합하려면 몇 가지 추가 구성이 필요하므로 애플리케이션이 더 복잡해질 수 있다.
- 학습: Spring Boot와 함께 Flyway를 사용하려면 새로운 명령과 규칙을 배워야 하므로 일부 개발자에게는 새로운 기술에 대한 학습이 필요하다.
- 기존 스키마와 충돌: Flyway에서 관리하지 않는 기존 스키마 변경 사항이 있는 경우 충돌 및 잠재적인 데이터 손실의 위험이 있다.
- 제한된 롤백 지원: Flyway는 마이그레이션 실패를 감지하고 오류 메시지를 제공할 수 있지만, 마이그레이션의 자동 롤백 기능은 제공하지 않으므로 수동 개입이 필요할 수 있다.
요약하면, Spring Boot와 함께 Flyway를 사용하면 손쉬운 통합, 버전 제어, 일관성, 반복 가능한 마이그레이션, 여러 데이터베이스 지원 등 여러 가지 이점을 얻을 수 있다. 하지만 추가 구성, 학습, 기존 스키마와의 충돌, 제한된 롤백 지원 등 몇 가지 잠재적인 단점도 있다.
초기 개발 및 배포시 Flyway 가 제공하는 데이터베이스 마이그레이션 간소화 기능을 사용하여 실행과 동시에 필요한 테이블들과 기초 데이터들에 대한 마이그레이션을 자동화는 제한된 목적이라면 좋은 선택일 것 같다.
Flyway에서 마이그레이션 SQL 파일은 반드시 다음 이름 패턴을 준수해야한다: ( ➜ 공식 문서)
- Part 1: "V" 는 버전 "U" 는 실행취소 마지막으로 "R" 은 반복 작업을 의미하며 스프립트 파일 언제나 이 문자로 시작해야 한다. 이들 시작 문자는 변경할 수 있다.
- Part 2: R (반복작업) 을 제외하고 점 또는 밑줄로 버전을 원하는 만큼 구분하여 사용할 수 있다. (예: 0, 1, 001, 1.2.3, 2021.09.24.12.55.32, ...)
- Part 3: "__" (밑줄 2개) 버전 파트와 설명 파트를 구분한다. 구분자는 변경할 수 있다.
- Part 4: 작업 설명으로 밑줄 또는 공백으로 단어를 구분할 수 있다.
- Part 5: 스크립트 확장자을 의미하며 변경이 할 수 있다.
Spring Boot 에서 Part 1 ~ Part 5 항목은 application.properties (또는 application.yml) 에 설정을 통하여 변경할 수 있다. ➜ 공식문서
Flyway 는 아래와 같이 의존성을 build.gradle 에 추가하는 작업으로 시작한다. (MySql 을 사용한다면 flyway-mysql 의존성 추가 필요)
dependencies {
implementation 'org.flywaydb:flyway-core'
implementation 'org.flywaydb:flyway-mysql'
}
데이터베이스 마이그레이션 SQL 파일 명명 규칙 중에서 변경 가능한 것들은 application.properties (또는 application.yml) 속성을 사용하여 필요에 맞게 조정한다.
위 설정의 경우 jar 파일에서 schema/mysql 스클립트 파일을 검색하여 마이그레이션을 실행하고 파일 이력 관리를 위하여 "flyway_schema_history" 테이블을 생성하여 관리하게 된다.
보안 : Spring Security
Spring Security 5.7.0-M2 버전 부터는 사용자의 컴포넌트 기반의 보안 설정 권장을 목적으로 WebSecurityConfigurerAdapter 을 더이상 사용하지 않는다. ➜ 스프링 공식 블로그템블릿엔진 : Freemarker
Thymeleaf, FreeMarker, Velocity 와 같은 템플릿 엔진은 일반적으로 HTML 페이지의 서버 측 렌더링을 위해 Spring Boot 애플리케이션에서 사용된다.
다음과 같은 경우라면 은 Spring Boot 애플리케이션에서 템플릿 엔진 사용을 고려할 충분한 이유가 된다.
- 서버 측 렌더링: 템플릿 엔진을 사용하면 서버 측에서 HTML을 렌더링할 수 있으므로 SEO, 접근성 및 성능을 개선할 수 있다.
- 재사용 가능성: 템플릿은 웹사이트의 여러 페이지 또는 섹션에서 재사용할 수 있으므로 코드 중복을 줄일 수 있다.
- 유지 보수성: 템플릿 엔진을 사용하면 프레젠테이션 로직과 비즈니스 로직을 분리할 수 있어 코드 유지 관리 및 수정이 용의하다.
- Spring Boot와의 손쉬운 통합: 많은 템플릿 엔진이 Spring Boot와 통합되어 있어 Spring Boot 애플리케이션에서 쉽게 사용할 수 있다.
반면 애플리케이션이 HTML 페이지의 서버 측 렌더링이 필요하지 않거나 프런트엔드 구축에 React 또는 Angular와 같은 클라이언트 측 프레임워크를 사용하는 것을 선호하는 경우 템플릿 엔진을 사용할 필요가 없을 수 있다.
freemarker 템플릿 엔진은 Spring Boot application properties (application.yml) 에 정의하거나 커스텀이 필요한 경우 WebMvcConfigurer 을 직접 구현하여 정의 하는 방법으로 사용한다.
https://docs.spring.io/spring-boot/docs/2.7.9/reference/html/application-properties.html
참고자료
- Building a Multi-Module Spring Boot Application with Gradle
- Creating a Multi Module Project
- Generating the database schema in a Spring Boot application
- Handle database migrations in a Spring Boot application with Flyway
- Samples for spring security
- Spring Security without the WebSecurityConfigurerAdapter
- CORS with Spring
- Spring Security Configuration - HttpSecurity vs WebSecurity
- Introduction to Using FreeMarker in Spring MVC
