흰 스타렉스에서 내가 내리지

도메인 모듈을 분리해보자 Storage 모듈을 Runtime Only로 의존하게 하고, Storage 모듈은 Domain 모듈을 Compile Only로 의존하게 된다. 이렇게 되면 실제 Runnable 한 HTTP API모듈 쪽은 Storage 모듈이 Runtime 의존이기 때문에 Storage 모듈의 존재 자체를 모른다. 오직 Domain 모듈만을 아는 구조가 되는 것이다. 그리고 Storage 모듈이 Domain 모듈을 Compile로 의존한다. 일단 다음과같은 폴더 구조를 만들고, 그전에 settings.gradle에 include 하는거 잊지말고 api 모듈에 의존성 다음과 같이 추가하고, db 모듈은 runtimeOnly로 바꾼다. 또 storage 모듈에서도 compileOnly로 domai..

DB 모듈을 추가해보자 만약 에플리케이션 모듈을 하나로 운영하는 곳을 보면 의존성이 이렇게 되어 있을 것이다. 이렇게 보다는, 다음과 같이 DB 모듈을 추가로 만들어보자 db 모듈을 분리하지 않으면, demo-api의 설정파일에 데이터베이스 관련된 설정들(엔드포인트, 아이디, 비번)이 들어갈 것이다. API 모듈에서는 실제 실행되는 모듈의 관심사와 밀접하게 연관된 설정들만 넣도록 하자. Kotlin에서 jpa를 사용하기 위해서 allOpen{}을 gradle 파일에 넣어준다. 위와 같이 jpa를 implementation 이 아닌 api 키워드를 이용해서 하면, 상위(여기서는 demo-api)에서 직접적으로 JPA Repository 같은 거를 사용할 수 있는 형태가 된다. 격리를 하는 것이 좋아보인다...

플러그인 버전이나 각종 변수들, 의존성 버전 같은 것들을 한 곳에 모아서 관리하는 방식을 알아보자. 루트에 gradle.properties 파일 추가 옆에 보고 작성 이렇게 변수를 작성해서 매핑 플러그인 같은 경우에도 예를들어 코틀린 버전을 올리거나 스프링부트 버전을 올리거나 할 때, 버전 정보가 파편화되있으면 관리하기 까다로운 부분이 있는데, 그것을 gradle.properties에 모아서 사용한다. 이것은 settings.gradle.kts에서 한다. 이렇게 하면 build.gradle.kts 에 plugins에 버전을 지울 수 있다. 이대로 demo-api 를 run 해보면 잘 실행이 되는 것을 볼 수 있다. 이런 식으로 관리하면 스프링 버전을 올리거나 코틀린 버전이 올라갈 때 대응이 쉬워진다. d..

include 추가 같은 이름의 디렉토리 추가 전체 src 폴더를 demo-api로 옮긴다. 원래 이런 구조로 되어있는 build.gradle 을 allprojects{}, subprojects{} 구조로 변경 spring-boot-starter-web 의존성은 모든 서브 모듈에 필요한게 아니라면 지운다. plugins{}는 지금 이런 구조로 되어 있는데, Root에 적용될 필요가 없다면 apply false 를 추가해준다. 모든 서브 모듈에 적용되어야 하는 플러그인을 추가해준다. apply(plugin = "org.jetbrains.kotlin.jvm") apply(plugin = "org.jetbrains.kotlin.plugin.spring") apply(plugin = "org.springfram..

# 멀티 모듈 프로젝트 구조가 왜 중요한가? - 나중에 변경하기 어렵다 - 리스크를 줄이기 위한 시작 멀티모듈 프로젝트는 빌드와 배포 프로세스에 밀접한 영향을 미친다. 시스템이 커져갈수록 빌드와 배포 프로세스도 복잡해지면서 나중에 이 프로젝트의 구조를 변경하게 되면, 빌드와 배포 프로세스 모두 변경해야한다. 우선은 META 라는 하나의 멀티모듈 프로젝트로 구성한다. META 모듈은 서비스의 기반이 되는 공통 도메인이다. 모든 모듈들에서 필요로 한다. Track 이라는 도메인은 MySQL에 적재를 하고, Lyric 이라는 가사 도메인은 MongoDB에 적재를 한다면, META 모듈은 어디에 위치시키고 어떻게 구현을 해야할까? META 모듈은 또 다른 멀티 모듈을 필요로 한다. 바로 유관 부서 및 업체 연동..

객체를 생성하기 위해서는 1. 생성자 패턴 2. 정적 메소드 패턴 3. 수정자 패턴 4. 빌더 패턴 등을 사용할 수 있다. 빌더 패턴의 장점 1. 필요한 데이터만 설정할 수 있다. 2. 유연성을 확보할 수 있다. 3. 가독성을 높일 수 있다. 4. 변경 가능성을 최소화할 수 있다. 1. 필요한 데이터만 설정할 수 있다. 객체의 한 파라미터가 필요없는 상황이라면, 생성자나 정적 메소드를 사용하는 상황이라면 dummy 값을 넣어주어야 한다. , 빌더를 이용하면 동적으로 이를 처리할 수 있다. 2. 유연성을 확보할 수 있음. 클래스에 새로운 변수를 추가한다면, 생성자의 코드를 수정해야 하는 상황에 놓인다. 하지만 빌더 패턴을 이용하면 새로운 변수락 추가되는 등의 상황이 생겨도 기존의 코드에 영향을 주지 않을 ..

Data Transfer Object 프로세스 사이에서 데이터를 전송하는 객체이다. DTO를 사용하며 중요한 정보를 노출시키지 않고 서버 간 통신을 원활하게 촉진할 수 있다. DTO는 필요한 데이터만 전송할 수 있다. 계층 간 데이터 전송을 위해 도메인 모델 대신 사용되는 객체이다. DTO는 어떠한 비즈니스 로직을 가져서는 안되며, 저장, 검색, 직렬화, 역직렬화 로직만을 가져야 한다. 도메인 대신 DTO을 사용하면 좋은 이유 DTO 대신 도메인 모델을 계층간 전달에 사용하면, UI 계층에서 도메인 모델의 메소드를 호출하거나 상태를 변경시킬 수 있다. 또한 UI화면마다 사용하는 도메인 모댈의 정보는 상이하다. 하지만 도메인 모델은 UI에 필요하지 않은 정보까지 가지고 있다. 이런 모든 도메인 모델 속성이..

ff

implementation 'org.springframework.boot:spring-boot-starter-data-rest'