멀티 모듈 기반 영화 예매 서비스 설계기 : 멀티 모듈 프로젝트 설계(3) - Layer 기반의 모듈 분리

이전 포스팅에서는 도메인별로 나눠진 멀티 모듈 구조(service-membership, service-movie 등)를 소개했었다.
하지만 실제 실습을 진행하면서 몇 가지 한계를 느꼈다.

• Redis 캐싱 최적화와 같은 기능 중심 개발을 하기에 도메인별 분리는 오히려 복잡했다.
• 도메인 간 기능이 얽힐 때, 레이어 경계를 넘는 작업이 불필요하게 많아졌다.
• 유지보수성과 테스트 효율성을 위해 더 명확한 계층 분리가 필요했다.

그래서 이번엔 도메인 중심이 아닌 Layer 중심의 구조로 재설계했다. 이 글은 그 구조와 설계 의도를 간단히 정리한 글이다.

---

🧱 새로운 프로젝트 구조

platform (루트 프로젝트)
├── bootstrap                    # 애플리케이션 실행 모듈 (모든 모듈 통합 실행)
├── adapter                      # Inbound / Outbound 어댑터 모듈
│   ├── in                       # 외부 요청 진입점 (Controller 등)
│   └── out                      # 외부 시스템 연동 (Persistence, API Client 등)
├── application                  # Application Layer (UseCase, Service, Command, DTO 등)
├── domain                       # 핵심 도메인 로직 (엔티티, 밸류, 도메인 서비스 등)
├── infrastructure               # 인프라 구성 (DB, Redis, Kafka 설정 등)
└── docs                         # 프로젝트 문서 및 ERD

---

🧩 각 계층의 역할

1️⃣ bootstrap - 진입점

• @SpringBootApplication이 붙은 메인 클래스 위치
• 로컬에서 통합 실행하거나 테스트할 때 사용
• 설정 파일도 이곳에 위치

2️⃣ adapter - 어댑터 계층 (Controller / Persistence)

• Inbound: 사용자의 요청을 받아들이는 컨트롤러
• Outbound: DB, 외부 API, 메시징 시스템과 연동하는 구현
• 구조상 외부 세계와 내부 비즈니스 로직을 분리하는 계층

3️⃣ application - 유즈케이스 계층

• 비즈니스 흐름을 정의
• 도메인과 어댑터 계층 사이의 중재자 역할
• UseCase, Service, Command, Response DTO 등을 포함

4️⃣ domain - 핵심 도메인 로직

• 엔티티, 밸류 객체, Enum, 도메인 서비스 등을 담음
• 외부 프레임워크(JPA 등)에 의존하지 않는 순수 Kotlin/Java 코드
• 설계의 핵심이며 가장 안정적인 계층

5️⃣ infrastructure - 인프라 설정

• DB, Redis, Kafka 설정 및 관련 빈 구성
• 실제 구현체 등록 (예: KafkaProducer, RedisTemplate 등)

---

🚧 왜 이 구조로 바꿨는가?

✅ 기능 단위 캐싱과 성능 최적화에 유리

• Redis 캐시를 서비스 단위로 적용할 때, 기능 중심 설계가 훨씬 유연하다.
• 계층이 명확하니 캐시 위치나 캐싱 전략을 도메인에 침범시키지 않고 깔끔하게 분리 가능.

✅ 테스트 작성이 쉬워짐

• 각 계층별로 모킹 대상이 명확해짐 (예: application에서 domain만 모킹)
• 외부와의 경계를 adapter에 집중시켜 테스트 대상을 축소시킴

✅ 유지보수성과 확장성 향상

• 구조가 단순해졌고, 역할이 더 명확해짐
• 기능 하나 추가할 때도 어딜 수정해야 할지 직관적임

---

💬 마무리

이번 리팩터링을 통해 “현재 요구사항과 실습 환경에 맞는 구조”가 중요하다는 걸 다시 체감했다.

• 레디스를 사용한 성능 초적화를 실습하기 위한 구조는 단순하고 명확해야 했다.
• 도메인 분리보다 기능 중심의 계층 분리가 성능 최적화에 더 잘 맞았다.
• 헥사고날 아키텍처는 여전히 유효하지만, 도입 시기는 기능 복잡도와 함께 고려해야 한다.