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

최근에 영화 예매 시스템을 멀티 모듈 구조로 구성해봤다. DDD + 헥사고날 아키텍처를 바탕으로 각 기능을 명확히 분리하고, 유지보수성과 확장성을 고려한 구조다. 이 글에서는 프로젝트 구조, 각 모듈의 역할, 그리고 설계 의도를 정리해본다.

---

📦 프로젝트 구조

platform
├── bootstrap                # 모든 모듈을 실행하는 엔트리 포인트
├── common                   # 공통 모듈 (DTO, 설정, 예외, 유틸 등)
├── service-membership       # 회원 관리 서비스
├── service-movie            # 영화 정보 및 상영 일정 관리
└── service-reservation      # 좌석 예약 및 예약 상태 관리

• platform: 루트 모듈. 하위 모듈 관리 및 공통 설정 담당
• bootstrap: 로컬에서 모든 서비스를 통합 실행하는 애플리케이션
• common: 전 모듈에서 공통으로 사용하는 설정, DTO, 예외 등
• service-*: 각각의 도메인별 독립 서비스

---

🧩 각 모듈 역할

1. bootstrap - 통합 실행 포인트

• @SpringBootApplication이 붙은 메인 진입점
• 로컬 환경에서 모든 서비스를 통합 실행
• 실제 운영에서는 각 서비스는 독립 실행 예정

2. common - 공통 기능 모듈

• 공통 DTO, 예외 처리, 설정 파일 (JpaConfig, RedisConfig)
• Swagger, Security 설정
• 각 서비스가 공통 코드를 중복 정의하지 않도록 분리

3. service-membership - 회원 관리

• 회원가입, 로그인, JWT 발급
• 사용자 인증 및 정보 관리
• 토큰 기반 인증 구현

4. service-movie - 영화 및 상영 일정 관리

• 영화 정보, 상영관, 좌석 배치, 상영 일정 CRUD
• 헥사고날 아키텍처 적용
  • Controller → Service → Domain → Adapter 구조
  • QueryMovieUseCase, MovieRepositoryPort로 포트/어댑터 분리
• DB는 JPA + MySQL

5. service-reservation - 좌석 예약 기능

• 사용자가 좌석을 선택하고 예약
• 예약 내역 확인 및 취소, 결제 확정 처리
• 토큰에서 사용자 정보를 추출해 처리

---

🗂 연관된 ERD 구조

서비스 간 데이터는 명확히 나뉘어 있지만, 핵심 엔터티 구조는 다음과 같다:

• USERS, MOVIES, THEATERS, SCHEDULES, SEATS, RESERVATIONS
• 예: 한 사용자는 여러 예약을 가질 수 있고, 각 좌석은 특정 상영 일정에 연결됨

USERS ||--o{ RESERVATIONS : "예약"
MOVIES ||--o{ SCHEDULES : "상영 일정"
THEATERS ||--o{ SCHEDULES : "상영관"
...

---

🔗 서비스 간 통신

각 서비스는 독립적으로 배포되며, 필요한 경우 REST API 또는 Kafka 이벤트를 통해 데이터를 주고받는다.

예:

• service-reservation이 좌석 예약 가능 여부를 확인할 때 → service-movie의 /schedules/{id}/seats/{id}/availability API 호출
• 회원 인증 → service-membership이 JWT 발급 및 검증

---

💡 마무리하며

이번 멀티 모듈 설계를 하면서 느낀 점은 다음과 같다.

• 공통 모듈을 잘 정리해두면 중복 코드가 줄고, 각 서비스는 자신의 도메인에 집중할 수 있다.
• 초기에 과도한 공통화는 오히려 독이 될 수 있으니, 적절한 경계 설정이 중요하다.
• 각 모듈은 "하나의 도메인만 책임진다"는 원칙을 지키는 것이 핵심이다.