기록

보호되어 있는 글입니다.

1. 이 글을 쓰게 된 이유Spring Boot에서는 흔히. -Dspring.profiles.active=xxx 옵션으로 프로필을 지정한다. 그런데 어느 날 ./gradlew test -Dspring.profiles.active=git 명령어를 실행했는데, git 프로필이 적용되지 않는 현상을 마주하게 되었다. 분명히 JVM 옵션을 줬는데 왜 안 될까? 이 의문을 해결하기 위해 콘솔 → Gradle → JVM → Spring Boot까지의 프로필 전달 구조를 깊게 파헤쳐 보았다. 결과적으로 테스트 시에는 JVM 옵션이 자동으로 적용되지 않는 구조라는 걸 알게 되었고, Gradle의 테스트 환경과 JVM 간의 동작 방식에 대한 이해가 중요함을 느꼈다.2. 기본 개념 정리2.1 JVM 옵션 -D란?JVM을 ..

설계 목표이 프로젝트에서 내가 세운 데이터 설계의 핵심 목표는 다음과 같았다.비즈니스 흐름을 자연스럽게 표현할 수 있어야 한다예매가 어떤 흐름으로 일어나는지, 각 데이터가 어떻게 연결되는지를 모델링 안에서 바로 드러나게 하고 싶었다.단순하지만 확장 가능한 구조를 만들자처음에는 단순하게 시작하되, "할인 정책 추가", "좌석 상태 관리", "복수 사용자 인증" 같은 변화에도 잘 견딜 수 있도록 설계하고자 했다.테이블 간의 책임을 명확하게 나누자하나의 테이블이 너무 많은 역할을 하지 않도록, 도메인 별로 기능을 쪼개고 의존성을 줄이려 했다.테이블 설계 흐름처음에는 그냥 머릿속에서 "사용자가 로그인하고, 영화를 보고, 예매를 한다"는 시나리오를 자연어로 풀어보는 데서 시작했다.그 다음으로 각 개체(Entity..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

이전 포스팅에서는 도메인별로 나눠진 멀티 모듈 구조(service-membership, service-movie 등)를 소개했었다.하지만 실제 실습을 진행하면서 몇 가지 한계를 느꼈다.Redis 캐싱 최적화와 같은 기능 중심 개발을 하기에 도메인별 분리는 오히려 복잡했다.도메인 간 기능이 얽힐 때, 레이어 경계를 넘는 작업이 불필요하게 많아졌다.유지보수성과 테스트 효율성을 위해 더 명확한 계층 분리가 필요했다.그래서 이번엔 도메인 중심이 아닌 Layer 중심의 구조로 재설계했다. 이 글은 그 구조와 설계 의도를 간단히 정리한 글이다.🧱 새로운 프로젝트 구조platform (루트 프로젝트)├── bootstrap # 애플리케이션 실행 모듈 (모든 모듈 통합 실행)├── ..

이번 포스팅에서는 영화 정보를 관리하는 service-movie 모듈을 헥사고날 아키텍처(Hexagonal Architecture) 기반으로 설계하고 구현한 과정을 자세히 소개한다. 이번에는 도메인 중심으로 책임을 분리하는 헥사고날 아키텍처의 힘을 실제 프로젝트에 적용해봤다.🎯 왜 헥사고날 아키텍처를 적용했는가?일반적인 계층형 구조에서는 Controller, Service, Repository로 기능을 나누지만, 시간이 지나면서 Service에 모든 책임이 몰리고, 비즈니스 규칙과 기술 코드가 뒤섞이기 쉬웠다.헥사고날 아키텍처는 다음과 같은 명확한 목표를 가지고 있다:핵심 도메인 로직 보호: 비즈니스 핵심 규칙은 외부 기술(JPA, Redis 등)에 의존하지 않아야 한다.기술 독립성 확보: 외부 시스템..

최근에 영화 예매 시스템을 멀티 모듈 구조로 구성해봤다. DDD + 헥사고날 아키텍처를 바탕으로 각 기능을 명확히 분리하고, 유지보수성과 확장성을 고려한 구조다. 이 글에서는 프로젝트 구조, 각 모듈의 역할, 그리고 설계 의도를 정리해본다.📦 프로젝트 구조platform├── bootstrap # 모든 모듈을 실행하는 엔트리 포인트├── common # 공통 모듈 (DTO, 설정, 예외, 유틸 등)├── service-membership # 회원 관리 서비스├── service-movie # 영화 정보 및 상영 일정 관리└── service-reservation # 좌석 예약 및 예약 상태 관리platfo..