3단계 - 수강신청(DB 적용) #827
Merged
3단계 - 수강신청(DB 적용) #827
+569
−14
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- SessionPolicy에 type() 메서드를 추가해 정책 종류를 명시 - FreeSessionPolicy / PaidSessionPolicy가 자신의 타입을 반환하도록 구현
- SessionRepository 인터페이스 추가 - JdbcSessionRepository를 통해 Session 저장 구현 - session 테이블 스키마 정의 - @jdbcTest로 저장 동작 검증
- JdbcSessionRepository에 findById 구현 - SessionPeriod, CoverImage, SessionPolicy 매핑
javajigi
approved these changes
Dec 31, 2025
Contributor
javajigi
left a comment
javajigi
left a comment
There was a problem hiding this comment.
2단계의 도메인 객체를 최대한 유지하면서 db 매핑 💯
고민 지점과 관련해 jdbc를 사용할 경우 같은 고민을 할 것 같아요.
현재 요구사항에서는 현재와 같이 구현해도 되는데요.
성능상 이슈가 있을 수도 있어 피드백 남겨 봤어요.
나머지 부분과 관련해 특별히 이견이 없어 바로 merge해요.
| mapCoverImage(rs), | ||
| mapPolicy(rs), | ||
| SessionStatus.valueOf(rs.getString("session_status")), | ||
| findEnrollments(id)); |
Contributor
There was a problem hiding this comment.
JPA와 같은 ORM을 쓸 경우 Lazy Loading을 통해 성능 이슈를 해결할 수 있을 것 같다.
그런데 jdbc의 경우 Session을 조회할 때마다 매번 모든 수강생 정보를 조회하는 것은 성능상 이슈가 되지 않을까?
현재와 같이 Session에 필요한 모든 데이터를 조회하는 메서드와 수강생과 같은 정보를 제외한 Session 기본 정보만 조회하는 메서드를 분리해 보는 것은 어떨까?
| this.enrollmentRepository = enrollmentRepository; | ||
| } | ||
|
|
||
| public void enroll(Long sessionId, Long studentId, Payment payment) { |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
안녕하세요! 수강신청 도메인 모델을 DB와 매핑한 Step3 pr입니다. 궁금한 사항도 같이 여쭤보려고 정리해봤습니다! 감사합니다.
❓ 질문(궁금한 사항)
Session 조회 시 Enrollment 매핑 위치에 대한 고민
현재 구현에서는
SessionRepository에서 Session을 조회할 때Enrollment까지 함께 조회하여 완전한 Session Aggregate를 구성하도록 구현했습니다.
즉, SessionRepository가 Session 조회, Enrollment 조회, Session + Enrollments 조립까지 모두 담당하는 구조입니다.
고민 지점
이 구조를 구현하면서 아래 두 가지 방식 중 어떤 접근이 더 적절한지 고민이 되었습니다.
1️⃣ Repository에서 Aggregate를 완전히 조립하는 방식
2️⃣ Service 계층에서 Repository를 조합하는 방식
현재 구현을 선택한 이유
Session을 Aggregate Root로 보고 Enrollment는 Session Aggregate에 속한 엔티티라고 판단했습니다.
Enrollment는 별도 테이블과 Repository를 통해 저장되지만 조회 시에는 Aggregate 단위로 다루는 것이 자연스럽다고 생각해서 SessionRepository에서 Enrollment까지 함께 조회하여 Session을 조립하는 방식을 선택했습니다.
질문
JDBC 환경에서 Aggregate Root를 조회할 때 Repository가 내부 구성 요소까지 함께 조회해 조립하는 방식이 적절한지 아니면 Service 계층에서 여러 Repository를 조합하는 방식이 더 바람직한지 의견을 듣고 싶습니다!
🤔 구현하면서 고민했던 부분들
1) 도메인 구조를 유지한 채 매핑하는 방향
RowMapper내부에서SessionPeriod,CoverImage,SessionPolicy등을 생성해Session생성자로 전달하는 구조로 구현했습니다.2) CoverImage는 Session과 함께 저장, Enrollment는 분리 저장
session테이블에 cover image 관련 컬럼을 함께 두고 Session 저장 시 같이 저장하도록 했습니다.3) Aggregate Root(Session)와 Repository 분리
Session.enroll()을 통해서만 생성되도록 설계했습니다.EnrollmentRepository에 위임하는 구조로 구현했습니다.