4단계 - 수강신청(요구사항 변경)

[ghtjr410]

수강신청(요구사항 변경) 과제 제출

안녕하세요!
수강신청(요구사항 변경) 과제 제출합니다.

스트랭글러 패턴 적용 과정

커밋 전략

모든 변경사항을 하나의 커밋에 담으면 단위가 너무 커집니다.

• PR 단위: 요구사항을 만족하는 완결된 기능
• Commit 단위: 빌드와 테스트가 통과하는, 작업 단계의 의미있는 원자적 단위 (기능은 미완결일 수 있음)

실무에서 PR 리뷰를 받는다고 가정하고, 커밋 히스토리만 봐도 변경 흐름을 파악할 수 있도록 작업을 나눴습니다.

SessionStatus → ProgressStatus + RecruitmentStatus 분리

기존 코드를 한 번에 바꾸지 않고, 빌드가 깨지지 않는 단위로 커밋을 나눴습니다.

1. Session에 새 필드 추가 (null) → 기존 생성자 유지
2. schema.sql 컬럼 추가 + Repository save 수정
3. Repository 조회에서 새 컬럼 읽기
4. validateStatus 로직을 새 필드 기반으로 변경
5. 기존 SessionStatus 제거

각 커밋마다 테스트가 통과하는 상태를 유지했습니다.

CoverImage → CoverImages (1:N)

DB가 이미 session_id를 FK로 가지는 1:N 구조여서, 도메인만 변경하면 됐습니다.
스키마 변경 없이 바로 교체가 가능한 경우는 점진적 전환 없이 진행했습니다.

고민한 지점

1. 도메인 로직 → 영속화 분리

// 도메인이 상태 변경하고 객체 반환
Enrollment approved = session.approve(studentId);

// Repository는 객체를 받아서 저장 (상태값 노출 X)
sessionRepository.updateEnrollment(approved);

Service에서 상태값을 직접 넘기면 도메인과 불일치할 수 있어서, 변경된 객체를 반환받아 저장하는 방식을 선택했습니다.

2. JDBC 한계 인식

JPA의 Dirty Checking이 없어서 수동 저장이 필요하지만, "도메인 로직 → 영속화" 순서를 명확히 하는 것으로 타협했습니다.

배운 점

• 스트랭글러 패턴: 빌드가 깨지지 않는 단위로 점진적 전환
• 커밋 단위: 빌드가 통과하는 원자적 단위로 커밋
• 전술적 판단: DB 구조가 이미 1:N이면 점진적 전환 없이 바로 교체 가능
• YAGNI: 요구사항에 없는 repo.updateEnrollmentStatus(상태값) 대신 repo.updateEnrollment(객체)로 최소 구현

---

도메인의 모든 비즈니스 로직(Session 생성, 상태 변경 등)을 Service에 구현하고 싶은 욕심이 있었습니다.

하지만 이번 단계의 핵심은 스트랭글러 패턴을 적용한 점진적 리팩터링이기 때문에,
변경된 기능 요구사항에 해당하는 수강 승인/취소만 Service에 구현하는 것으로 범위를 제한했습니다.

리뷰 잘 부탁드립니다!

[javajigi]

4단계 미션의 핵심 경험이 스트랭글러 패턴 기반으로 점진적인 리팩터링 경험하는 것인데요.
pr 본문과 코드를 보니 충분히 의미있는 경험 한 것 같아요 💯
특별히 피드백할 부분이 없네요.
이 미션 여기서 마무리할께요. 수고했음다.