자바로 스프링 프레임워크를 직접 만들어보는 시리즈, 3편이다.1편에서 프로젝트 생성 및 @Component 어노테이션을 만들었고, 2편에서 BeanDefinition을 만들었다.이제 둘을 이어붙일 차례다. 이번 편에서 만들 것"지정한 패키지 아래에서 @Component 붙은 클래스를 모두 찾아 BeanDefinition 목록으로 변환" 해주는 컴포넌트.진짜 스프링에서 이 일을 하는 클래스가 ClassPathBeanDefinitionScanner이다. 나도 같은 이름으로 만들 것이다. 스캐너가 하는 일"com.mini.spring.sample" 같은 패키지 이름을 받는다그 패키지 아래 모든 클래스를 찾는다 ← 이게 까다롭다각 클래스에서 @Component가 붙어있는지 확인 ← 리플렉션붙어 있으면 BeanD..

프로젝트 생성에 이어서 이번에는 BeanDefinition의 개념에 대해 다뤄볼 것이다.BeanDefinition를 직역하면 "빈 정의"이다.그렇다면 여기에서 사용하는 "빈"이란 무엇일까?빈의 개념부터 짚고 넘어가보자. 빈(Bean)빈(Bean) : "스프링 컨테이너가 관리하는 자바 객체"를 의미한다. 그냥 객체랑 다른 점자바 객체와 빈을 코드로 비교해보자면 아래와 같다.// 그냥 객체 — 내가 직접 만들고 직접 관리HelloService a = new HelloService();a.hello();여기에서 a는 내가 new로 만들고, 내가 다 쓰고 나면 알아서 가비지 컬렉션이 된다.생성과 소멸을 우리가 책임진다. // 빈 — 컨테이너가 만들고 컨테이너가 관리ApplicationContext conte..

취업 준비를 하면서 혼자 톰캣도 직접 자바 코드로 짜보고 (블로그에 작성하진 않았지만..) 알고리즘 문제도 종종 풀고 있다.하지만 어떤 프로젝트를 해야할지 너무 막막했지만 이전에 톰캣을 직접 구현해본 것처럼 이번에는 자바 스프링 프레임워크를 구현해보고 싶었다. 사실 이미 잘 만들어져있는 프레임워크나 소스들을 왜 굳이 내가 하나씩 다시 구현할까 싶겠지만 나는 주변 사람들한테 cs 관련 개념이 매우 중요하다는 사실을 알게 되었고, 나 자신도 이에 대해 생각해봤을 때 부족하다는 사실을 누구보다 잘 알고 있었다.그래서 cs공부를 제대로 해보고자 이러한 개념들을 좀 딥하게 파보려고 한다.우선 클로드를 활용하여 전체적인 로드맵을 잡았다 전체 로드맵프로젝트 생성 & 핵심 어노테이션BeanDefinition — 빈의 ..

테스트 목표지금까지 구현한 기능은 다음과 같다콘서트 목록 조회특정 콘서트 공연 일정 조회이 기능이 정상적으로 동작하는지 검증하기 위해 테스트 코드를 작성한다 테스트 대상ConcertService검증할 기능콘서트 목록 조회특정 콘서트의 공연 일정 조회 테스트 환경Spring Boot에서 Repository + JPA 기반 테스트를 진행할 때는 보통 다음 어노테이션을 사용한다@SpringBootTest@Transactional 각 어노테이션에 대한 설명 @SpringBootTest - 전체 Spring Context 실행@Transactional - 테스트 후 DB 롤백 ConcertServiceTest 코드package com.example.Ticketing.domain.concert.service;..

구현 목표이전 글에서는 ConcertService와 ConcertScheduleRepository를 구현하여 콘서트 조회 기능의 기반을 만들었다.이번 글에서는 Service를 사용하는 Controller 계층을 구현하여 실제 API를 완성한다 구현할 APIGET /concertsGET /concerts/{concertId}/schedules 사용자 흐름콘서트 목록 조회 ↓특정 콘서트 선택 ↓공연 일정 조회 Controller의 역할Spring Boot의 기본 계층 구조는 다음과 같다Controller → Service → Repository → DB이 중 Controller는 클라이언트의 요청을 받아 Service를 호출하는 역할을 한다 Controller 구현package com.exam..

구현 목표티켓팅 시스템에서 사용자의 기본 흐름은 다음과 같다콘서트 조회 ↓공연 일정 조회 ↓좌석 조회 ↓좌석 예약 ↓결제이번 글에서는 이 흐름 중 콘서트 공연 일정 조회 기능을 구현한다 구현할 기능 : 특정 콘서트의 공연 일정 조회 이를 위해 다음 두 가지를 구현한다ConcertScheduleRepository 조회 메서드 추가ConcertService 구현 Repository 메서드 추가현재 ConcertScheduleRepository는 다음과 같이 기본 CRUD 기능만 제공하는 상태였다package com.example.Ticketing.domain.concert.repository;import com.example.Ticketing.domain.concert.entity.Conce..

대규모 트래픽을 제어하여 단 1명에게만 좌석을 할당하는 데 성공했고, 멱등성을 보장하여 안전하게 결제까지 마쳤다.하지만 티켓팅 시스템에는 한가지 치명적인 예외상황이 존재한다 "좌석을 선점(PENDING)해 놓고, 제한 시간(5분) 내에 결제를 완료하지 않으면 어떻게 될까?" 이 좌석을 영원히 RESERVED 상태로 방치한다면, 정작 티켓을 사고 싶어 하는 다른 사용자들은 예매할 기회를 잃게 된다. 이번 포스팅에서는 Spring Boot의 스케줄러(Scheduler)를 활용하여 제한 시간이 지난 예약을 주기적으로 찾아내어 취소하고, 좌석을 다시 예매 가능 상태(AVAILABLE)로 되돌리는 로직을 구현해보겠다 Spring Scheduling 활성화스프링 부트에서 스케줄러를 사용하려면 우선 애플리케이션 메..

예매의 동시성 문제를 해결했다면, 다음으로 마주하는 실무적인 고민은 결제 시스템의 안전성이다 사용자가 결제를 진행하는 도중 네트워크 지연이나 타임아웃이 발생하여 클라이언트가 결제 요청을 재싣도하는 상황을 가정해보겠다. 만약 서버가 이를 새로운 요청으로 착각하여 결제를 중복 승인한다면, 치명적인 금전적 사고로 이어진다 이번 포스팅에서는 동일한 요청이 여러 번 들어와도 시스템 상태가 한 번만 변경되도록 보장하는 멱등성(Idempotency)을 paymentKey를 활용하여 설계하고 구현해보겠다 멱등성 보장 전략: 이중 방어선 구축멱등성을 완벽하게 보장하기 위해 애플리케이션 계층과 데이터베이스 계층에서 이중 방어선을 구축했다 DB 계층 (Unique Constraint): 이전 포스팅의 DDL 설계 단계에서..