3주차 - WIL (Weekly I Learned)

🧐 3주차 과제 : 비즈니스 로직 개발 및 단위 테스트 작성

1. 콘서트 조회 : 레이어드 아키텍처

2. 포인트 충전 기능 : 레이어드 아키텍처

3. 예약/결제 기능 : 클린 아키텍처

 

✅ Keep (잘한 점 / 유지할 점)

- DDD구조로 콘서트, 포인트, 예약/결제 기능을 도메인별로 나누어 구현하면서, 레이어드 아키텍처 구조에 익숙해졌다. (기존에 항상 구현하던 방식이 레이어드여서 이미 익숙했지만..ㅎㅎ)

- 예약과 결제를 하나의 흐름으로 구성하고, 단위 테스트도 서비스 레벨에서 꼼꼼히 작성해보며 테스트 작성 능력이 조금 더 익숙해졌다.

- 스프링 스케줄러를 이용한 좌석 상태 변경 로직(EXPIRED → HOLD → AVAILABLE)을 설계·구현하고, 테스트해보며 시간 기반 로직도 경험할 수 있었다.

- Docker 기반의 MySQL 컨테이너를 띄운 뒤 테이블을 직접 설계하고 초기 데이터를 삽입해보았다.

 

❗️ Problem (문제점)

- 클린 아키텍처로 구현을 시도해보려 했지만, 실제로 의존성 방향을 완전히 분리하고 계층을 구성하는 데 어려움을 느껴, 기존 익숙한 레이어드 방식으로만 구현했다. (레이어드 구현 후 클린으로 변경예정이었으나 아직 못함)

- 예약/결제 실패 시에도 로그용 테이블에 insert하고자 했으나, 트랜잭션 롤백으로 인해 INSERT가 되지 않아 로깅/저장 전략에 대해 조금 더 고민하게 되었다.

 

💡 Try (해결을 위한 시도)

- 스케줄러 로직을 설계하면서 시간 기준 releasedAt을 활용하고, 좌석의 상태에 따라 전이되도록 구현하여 반복적인 상태 체크가 가능하도록 만들었다.

- 단위 테스트 작성 시 mock 데이터를 세밀하게 구성해 실제 상황과 유사하게 테스트되도록 신경 썼다.

 

💬 이번 주 알게 된 것들

- 예외 발생 시 트랜잭션의 롤백 여부는 예외 타입에 따라 다르며, 커스텀 예외는 RuntimeException을 상속하거나 rollbackFor 옵션을 명시해야 롤백이 일어난다.

- 상태 기반 스케줄러는 시간 기준을 명확하게 설정해두고, releasedAt 등 필드를 기반으로 동작하게 하게 구현할 수 있다.

 

 

🔁 지난 주 목표 회고

[✔] 콘서트 조회 기능 구현 및 단위 테스트 작성

[✔] 포인트 조회, 충전, 사용 기능 구현 및 단위 테스트 작성
[✔] 예약/결제 기능 구현 및 단위 테스트 작성
[✔] 스케줄러 구현 및 좌석 상태 전이 로직 적용

[❌] 클린 아키텍처로 구조 변경 (시간 부족으로 미완)

 

🎯 다음 주 목표

- 1주, 2주차에 못했던 거 적용해서 보완해보기

- 클린 아키텍처로 예약/결제 도메인 일부 분리 적용 시도

- 대기열 토큰 관련 비즈니스 로직 설계 및 단위 테스트 작성