3단계 - 수강신청(DB 적용)

[JoonKyoLee]

안녕하세요! 수강신청 도메인 모델을 DB와 매핑한 Step3 pr입니다. 궁금한 사항도 같이 여쭤보려고 정리해봤습니다! 감사합니다.

---

❓ 질문(궁금한 사항)

Session 조회 시 Enrollment 매핑 위치에 대한 고민

현재 구현에서는 SessionRepository에서 Session을 조회할 때
Enrollment까지 함께 조회하여 완전한 Session Aggregate를 구성하도록 구현했습니다.
즉, SessionRepository가 Session 조회, Enrollment 조회, Session + Enrollments 조립까지 모두 담당하는 구조입니다.

고민 지점

이 구조를 구현하면서 아래 두 가지 방식 중 어떤 접근이 더 적절한지 고민이 되었습니다.

1️⃣ Repository에서 Aggregate를 완전히 조립하는 방식

• SessionRepository가 Session과 Enrollment를 함께 조회
• 항상 완전한 Session을 반환

2️⃣ Service 계층에서 Repository를 조합하는 방식

• SessionRepository는 Session만 조회
• EnrollmentRepository는 Enrollment만 조회
• Service 계층에서 두 결과를 조합

현재 구현을 선택한 이유

Session을 Aggregate Root로 보고 Enrollment는 Session Aggregate에 속한 엔티티라고 판단했습니다.
Enrollment는 별도 테이블과 Repository를 통해 저장되지만 조회 시에는 Aggregate 단위로 다루는 것이 자연스럽다고 생각해서 SessionRepository에서 Enrollment까지 함께 조회하여 Session을 조립하는 방식을 선택했습니다.

질문

JDBC 환경에서 Aggregate Root를 조회할 때 Repository가 내부 구성 요소까지 함께 조회해 조립하는 방식이 적절한지 아니면 Service 계층에서 여러 Repository를 조합하는 방식이 더 바람직한지 의견을 듣고 싶습니다!

---

🤔 구현하면서 고민했던 부분들

1) 도메인 구조를 유지한 채 매핑하는 방향

• 이번 단계의 목표가 “도메인 구조를 유지한 채 DB에 매핑”이라고 이해했습니다.
• 별도의 DB 전용 엔티티를 만들기보다는 JDBC Repository에서 도메인 객체를 직접 조립하는 방식을 선택했습니다.
• RowMapper 내부에서 SessionPeriod, CoverImage, SessionPolicy 등을 생성해 Session 생성자로 전달하는 구조로 구현했습니다.

---

2) CoverImage는 Session과 함께 저장, Enrollment는 분리 저장

• CoverImage는 Session 생성 시 항상 함께 존재하는 값 객체이며 Session의 상태를 구성하는 속성이라고 판단했습니다.
• 따라서 session 테이블에 cover image 관련 컬럼을 함께 두고 Session 저장 시 같이 저장하도록 했습니다.
• 반면 Enrollment는 수강 신청이라는 행위의 결과로 생성되며 Session 생성 시점에는 존재하지 않기 때문에 별도의 테이블과 Repository로 분리했습니다.

---

3) Aggregate Root(Session)와 Repository 분리

• Session은 수강 신청 규칙을 통제하는 Aggregate Root로 두고 Enrollment는 Session.enroll()을 통해서만 생성되도록 설계했습니다.
• 실제 저장은 EnrollmentRepository에 위임하는 구조로 구현했습니다.