najang 님의 블로그

🧠 이번 주에 새로 배운 것- 낙관적 락(@Version) vs 비관적 락(SELECT FOR UPDATE) 선택 기준 - 동시성 윈도우(Race Condition Window) 개념과 이중 방어 패턴 - 원자적 UPDATE(@Modifying + WHERE 조건)로 쿠폰 사용 처리 - CountDownLatch로 실제 Race Condition을 재현하는 테스트 작성법 - Application Layer vs Domain Layer 책임 분리 (OrderApplicationService, LikeApplicationService) 💭 이런 고민이 있었어요- 쿠폰 발급에서 existsByUserIdAndCouponTemplateId() 체크 후 save() 사이 동시성 윈도우 문제 - 낙관적/비관적 ..

🧠 이번 주에 새로 배운 것시퀀스 다이어그램의 적정 수준: 설계 단계에서 API 명세나 SQL 쿼리 같은 세부 구현에 매몰되면 오히려 전체 흐름을 놓칠 수 있다는 걸 배웠습니다. 추상화 단계를 높여 "어떤 기능이 어떤 흐름으로 이어지는지"를 명확히 정의하는 것이 설계의 핵심임을 깨달았습니다.동시성 제어 전략의 트레이드 오프: 재고 차감처럼 데이터의 정확성이 생명인 도메인에서는 처리량(Throughput)을 조금 포기하더라도 비관적 락(Pessimistic Lock)이 더 안전한 선택지가 될 수 있음을 학습했습니다. 💭 이런 고민이 있었어요낙관적 락 vs 비관적 락: 충돌이 잦을 것으로 예상되는 주문 도메인에서 SELECT FOR UPDATE를 활용한 비관적 락을 선택했습니다.데드락(Deadlock) ..

🧠 이번 주에 새로 배운 것테스트를 Unit / Integration / E2E 세 단계로 나눠서 작성하니, 각 테스트가 검증하는 책임 범위가 훨씬 명확해진다는 걸 체감했습니다.UnitMockito를 사용해 UserService의 비즈니스 로직만을 독립적으로 검증IntegrationTestContainers(MySQL)를 활용해 Spring Context와 JPA Repository를 함께 띄우고, 실제 DB 연동까지 포함한 영속석 계층 통합 검증E2ETestRestTemplate으로 애플리케이션을 실제로 실행한 뒤, HTTP 요청부터 인증 필터/인터셉터를 거쳐 응답이 반환되기까지의 전체 흐름 검증PasswordPolicy처럼 검증 로직을 별도 객체로 분리하니, 정책 변경 시 서비스 코드를 건드리지 않..