Java로만 구축했던 스프링을 Kotlin으로 구축 해 봅시다.
공식 홈페이지 에도 잘 설명이 되어 있습니다.
구축 전 간단히 알아둬야 할 개념
이 프로젝트는 멀티모듈 프로젝트 입니다.
모듈이란 패키지보다 한 단계 위의 디렉토리입니다.
바꿔 말하면 하나의 모듈에는 여러 패키지가 담겨있습니다.
과거의 Spring 프로젝트들은 단일 모듈안의 여러 패키지로만 프로젝트를 구성 했기 때문에
- 서로 다른 프로젝트에서 공통된 코드를 사용하고 있다면 같은 코드를 복붙해서 사용해야 한다.
- 여러 프로젝트를 사용하기 위해 IDE도, 인스턴스도 N개를 실행해야 한다.
- 각 패키지끼리의 의존성이 강해 하나의 수정이 N개의 오류를 발생시킬 수 있다.
- 프로젝트 규모가 커지거나 코드가 길어지면 각 패키지가 담당하는 역할이 모호해진다.
등등.. 여러 문제점이 야기됩니다.
그러나 멀티모듈 프로젝트는 각각의 모듈이 서로 독립적이고 간섭하지 않기 때문에 위와 같은 문제가 발생하지 않아
- 하나의 프로젝트에 중복되는 코드가 많이 사라진다.
- 여러 프로젝트를 모듈화시켜 하나의 IDE, 인스턴스에서 실행할 수 있다.
- 각각의 모듈과 패키지는 독립적인 역할을 하기 때문에 의존성이 낮아진다.
등의 장점이 생기게 됩니다.
CQRS 패턴을 따릅니다.
CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리) 을 나타냅니다. 이름처럼 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다.
CQRS에서 명령은 시스템의 상태를 변경하는 작업이고, 조회는 시스템의 상태를 반환하는 작업입니다. DB에서 무언가의 데이터를 읽어오고 처리하는 간극에 이미 데이터가 변경될 가능성을 염두하고 아예 분리해 관리하자는 패턴입니다.
CQRS의 장점에는
- Read와 CUD 각각에 더 최적화된 DB구성을 통해 성능을 향상시킬 수 있다.
- 여러 사용자가 동일한 데이터에 동시에 액세스 하는 공동 작업 도메인. CQRS를 사용 하면 도메인 수준에서 병합 충돌을 최소화 할 수 있다.
- 읽기 모델에는 비즈니스 논리 또는 유효성 검사 스택이 없으며 뷰 모델에서 사용할 DTO가 반환된다. 결과적으로 읽기 모델과 쓰기 모델의 일관성이 유지된다.
- 데이터의 성능을 데이터 쓰기의 성능과 별도로 세부적으로 조정 해야 하는 시나리오는 특히 읽기 수가 쓰기 수보다 훨씬 많은 경우에 발생 합니다. 이 시나리오에서는 읽기 모델을 확장 하지만 몇 개의 인스턴스에서만 쓰기 모델을 실행할 수 있다.
- 개발자 중 한 팀은 쓰기 모델에 포함되는 복잡한 도메인 모델에 집중하고, 또 한 팀은 읽기 모델과 사용자 인터페이스에 집중할 수 있다.
- 시스템이 시간이 지나면서 진화할 것으로 예상되어 여러 버전의 모델을 포함할 수 있거나 비즈니스 규칙이 정기적으로 변하는 시나리오에서 하위 시스템 하나의 일시적인 장애가 다른 시스템에 영향을 주지 않는다
- 출처: CQRS 패턴
등이 있습니다.
우리는 이 두 가지를 참고해
API: 서버 통신을 위한 REST API를 모아둔 모듈
- Config: DB, JPA, WebMvcConfig 등 각종 설정 파일을 모아둔 패키지
- Controller: 클라이언트에게 서비스를 제공하는 RestController들의 모임 패키지
- Dto: 클라이언트로부터 받는, 그리고 주는 DTO를 각각 IN / OUT으로 구분해서 책임을 분리
- Filter: api 서브모듈에서만 사용하는 서블릿 필터 패키지
- Intercepter: 스프링 인터셉터
- Service: 컨트롤러부터 요청을 받아 도메인 엔티티에 비즈니스 로직을 위임, 요청을 처리한 후 다시 컨트롤러에게 반환
- Util: 특정 레이어에 두기 애매한 유틸 성 로직 모음
Domain: 시스템의 엔티티 및 핵심 비즈니스 로직을 처리하는 모듈
- Converter: 데이터베이스의 데이터 타입과 애플리케이션 소스 코드의 데이터 타입 변환 담당
- Exception: 도메인 엔티티에서 비즈니스 로직 처리시 발생할 수 있는 예외 클래스
- Model: 도메인 엔티티 클래스
- Projection: 쿼리 최적화를 위해 도메인 엔티티의 일부 속성만 조회할 때 사용
- Repository: DB CRUD 담당
Lib: API도, Domain도 아니지만 필요한 Lib성 모듈
- security: 스프링 Security와 JWT
이렇게 디렉토리 구조를 구축하고 사용 합니다. 물론 코틀린으로요!
다음 문서에서는 하나의 서버통신을 위한 단계를 DB 설정부터 기술하도록 하겠습니다.
코프링의 장점을 알아보고 싶다면?
나와 같은 마음.. 참고 👇
코틀린이란 왜 쓰는가
코틀린과 자바
코틀린+스프링(코프링) 6개월 후기
프로젝트 구성 참고
멀티모듈 프로젝트 구성1
멀티모듈 프로젝트 구성2
양방향 연관관계 주의
객체지향 프로그래밍과 메세지
