Coding-Su

TL;DR4개 레이어(interfaces, application, domain, infrastructure)로 구성된 레이어드 아키텍처를 적용했다.의존 방향은 interfaces → application → domain ← infrastructure 단방향으로 강제하고,DIP(의존성 역전 원칙)로 domain이 Spring/JPA/BCrypt 같은 인프라 기술을 모르는 구조를 만들었다.Introduction & Goals커머스 백엔드 API를 설계할 때 두 가지 문제를 피하고 싶었다.기술 의존 전파: Spring Security, JPA 같은 인프라 기술이 비즈니스 로직에 직접 침투하는 것책임 불명확: "이 코드는 어느 레이어에 있어야 하나?"라는 질문에 명확히 답할 수 없는 구조레이어드 아키텍처 + D..

TL;DR주문/결제 시스템에서 동시성 문제를 하나씩 해결할 때마다 새로운 문제가 연쇄적으로 드러났다.SAGA 패턴 → 취소 시 Lost Update → 데드락 → 이중 취소까지 6개 문제를 차례로 발견하고,SELECT FOR UPDATE와 정렬 기반 락 획득 순서로 모두 해결했다.문제 1: 결제 실패 중 새 주문 → 트랜잭션 분리로 보상 범위 명확화 (보상 자동 실행은 미구현) ↓문제 2: 주문 취소 시 재고 Lost Update → 취소에도 SELECT FOR UPDATE 추가 ↓문제 3: 여러 상품 주문 시 데드락 → productId 오름차순 정렬로 해결 ↓문제 4: 이중 취소 요청 → Order에 SELECT FOR UPDATE 추가 ↓문제 5: PENDING 방치 → 배치 ..

이론으로만 알던 TDD와 DDD를 loopers에서 직접 적용하면서 "왜 이렇게 해야 하는가"를 몸으로 깨달은 기록.TDD 방법론은 무엇인가?TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이다. 소프트웨어 방법론으로 작은 단위 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. TDD의 개발 절차에는 Red -> Green -> Refactor를 반복하면서 Red 단계에서는 테스트 케이스에 맞는 실패하는 테스트 코드를 먼저 작성하고, Green 단계에서는 테스트를 성공시키기 위한 최소한의 코드를 작성한다. 마지막으로 Refactor 단계에서 중복 코드 제거, 일반화 등 리팩토링을 한다. 이 과정에서 중요한것은 실패하는 테스트 코드를 작성하기..