코디잉

🧐 5주차 과제 1. 동시성문제 - ① 좌석 임시배정 (중복예약)2. 동시성문제 - ② 포인트 차감/충전3. 동시성문제 - ③ 결제, 스케줄러 간 좌석 상태 충돌✅ Keep (잘한 점 / 유지할 점)- 멀티스레드 테스트를 통해 실제 동시성 문제를 재현하고, 문제를 해결할 수 있는 전략(비관적 락 / 조건부 UPDATE)을 각각 상황에 맞게 적용함 - 스케줄러와 결제 로직 간의 상태 충돌 가능성을 인지하고, 이를 테스트 코드로 검증 - 예외 상황에서도 결제 실패 이력을 남길 수 있도록 별도 트랜잭션 분리를 적용 (REQUIRES_NEW)- 요청 DTO에 검증 애노테이션(@NotBlank, @Min 등)을 활용해 잘못된 요청을 조기 차단할 수 있도록 개선 ❗️ Problem (문제점)- SeatStatus..

🧐 4주차 과제 1. 예약/결제 기능 : 레이어드 아키텍처 ➡ 클린 아키텍처로 전환하기2. 테스트 컨테이너로 테스트 가능하도록 구성 3. 기능별 통합테스트 작성 ✅ Keep (잘한 점 / 유지할 점)- 클린 아키텍처의 구조를 이해하고, 레이어드 아키텍처로 구현했던 패키지를 클린 아키텍처로 전환함- 대기열 토큰 로직을 설계하면서 예매 흐름(조회 ➡ 예약 ➡ 결제)의 전반적인 흐름을 제어하는 구조를 구성해봄 - 상태 기반의 접근 방식(READY / EXPIRED 등)을 적용하고, 클린 아키텍처 구조 내에서도 Validator 컴포넌트를 활용해 공통 검증 로직을 분리함 ❗️ Problem (문제점)- DB 제약조건(UNIQUE) 설정으로 인해 이미 EXPIRED 된 토큰이 있음에도 발급이 막히는 문제가 발생..

🧐 3주차 과제 : 비즈니스 로직 개발 및 단위 테스트 작성 1. 콘서트 조회 : 레이어드 아키텍처 2. 포인트 충전 기능 : 레이어드 아키텍처3. 예약/결제 기능 : 클린 아키텍처 ✅ Keep (잘한 점 / 유지할 점)- DDD구조로 콘서트, 포인트, 예약/결제 기능을 도메인별로 나누어 구현하면서, 레이어드 아키텍처 구조에 익숙해졌다. (기존에 항상 구현하던 방식이 레이어드여서 이미 익숙했지만..ㅎㅎ)- 예약과 결제를 하나의 흐름으로 구성하고, 단위 테스트도 서비스 레벨에서 꼼꼼히 작성해보며 테스트 작성 능력이 조금 더 익숙해졌다.- 스프링 스케줄러를 이용한 좌석 상태 변경 로직(EXPIRED → HOLD → AVAILABLE)을 설계·구현하고, 테스트해보며 시간 기반 로직도 경험할 수 있었다.-..

🧐 2주차 과제 : 선택한 시나리오 분석1. 시나리오 선택 및 github 프로젝트 Milestone 작성: 콘서트 예약 서비스 2. 분석 문서 작성 ◾ 요구사항 정의서 ◾ 시퀀스 다이어그램 ◾ 클래스 다이어그램 ◾ ERD ◾ 상태 다이어그램 ◾ 인프라 구성도 ✅ Keep (잘한 점 / 유지할 점)- 콘서트 예약 서비스를 선택하고, 시나리오를 구체화하여 요구분석을 작성하며 도메인 흐름을 명확히 잡으려고 했다.- 실제 구현을 생각하며, ERD, 상태/시퀀스/클래스 다이어그램을 정리했다. ❗️ Problem (문제점)- 상태/시퀀스/클래스 다이어그램을 작성하는게 막막해서 흐름을 잡는데 시간이 오래걸렸다.- 좌석의 상태 변화에 대해 고민이 많아 설계가 반복적으로 바뀌었다. (좌석 임..