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

[Eundms]

1. 1:N 관계 - Session : Registration (수강신청)

도메인 모델:
Session (1) ──── (N) Registration

테이블 설계:
session (id, course_id, term, ...)
registration (id, session_id, student_id, enrolled_at) -- FK로 session_id 참조

고민한 부분:

• Session 조회 시 findRegistrationsBySessionId()로 연관된 Registration들을 조회해서 Registrations 객체로 조립
• maxCapacity 정보는 Session 테이블에 저장하고, Registrations 생성 시 전달:
  Registrations registrations = findRegistrationsBySessionId(id, entity.getMaxCapacity());

2. 1:1 관계 - Session : SessionCoverImage (커버 이미지)

도메인 모델:
Session (1) ──── (1) SessionCoverImage

테이블 설계:
session (id, ...) -- 이미지 정보를 포함하지 않음
session_cover_image (id, session_id, width, height, extension, capacity) -- FK로 session_id 참조

고민한 부분:

• 1:1이지만 별도 테이블로 분리 (Session 테이블에 임베딩하지 않음)
• 분리한 이유 :
  • 이미지 관련 필드가 많아서 (width, height, extension, capacity)
  • Session 테이블의 책임을 줄이기 위해
  • 이미지가 없을 수도 있는 경우 (null 허용)
• Session 조회 시 findCoverImageBySessionId()로 조합:
  SessionCoverImage coverImage = findCoverImageBySessionId(id);
  return SessionMapper.toDomain(entity, registrations, coverImage);

3. 값 객체(VO) 처리 - Flat하게 저장

SessionType (FreeType/PaidType) 처리:
session (
type varchar(10), -- 'FREE' or 'PAID'
max_capacity int, -- PaidType의 maxCapacity
tuition_fee bigint -- PaidType의 tuitionFee
)

Mapper에서 복원:
if ("FREE".equals(entity.getType())) {
type = new FreeType(registrations);
} else {
type = new PaidType(entity.getTuitionFee(), registrations);
}

4. Entity/Mapper 패턴 도입

구조:
Domain Object ←→ Entity ←→ DB
↑ ↑
└── Mapper ──┘

• Entity: DB 테이블과 1:1 매핑되는 순수 데이터 객체
• Mapper: Domain ↔ Entity 변환 책임
• Domain 객체는 DB 구조를 모르고, Entity는 비즈니스 로직을 모름

핵심 설계 결정 요약

관계	도메인	테이블 전략	조회 전략
1:N	Session:Registration	별도 테이블 + FK	조회 시 join해서 조립
1:1	Session:CoverImage	별도 테이블 + FK	조회 시 추가 쿼리
VO (다형성)	SessionType	단일 테이블에 type 컬럼	type에 따라 if-else 생성
VO (단순)	SessionPeriod, Term	Session 테이블에 flat 저장	조회 시 VO로 감싸서 생성

[javajigi]

기존의 도메인 객체를 유지하면 db 매핑 넘 잘 했네요. 💯
Entity/Mapper 패턴을 도입해 도메인 객체가 db 연결로 인해 영향을 받지 않도록 최소한 것도 인상적이네요.
Entity 객체의 사용에 대한 피드백이 있어 남겨봤어요.
은정님은 어떻게 생각하는지 결과가 궁금하네요.

[javajigi]

👍

[javajigi]

도메인 객체에 db 매핑 관련 작업을 오염 시키지 않기 위해 Entity 추가 👍

[javajigi]

매번 Mapper를 생성하는 것이 번거롭다면 https://mapstruct.org/ 와 같은 라이브러리 사용을 고려해 보는 것도 방법일 수 있겠다.

[javajigi]

이 미션의 객체 설계에서 수강 신청 가능 여부를 확인하는 것이 복잡도가 가장 높은 부분이이다.
이 부분은 Session 객체 내에 두는 것이 아니라 아래와 같이 Session을 통해 수강신청에 필요한 객체를 아래의 Enrollment와 같은 객체로 생성한 후 위임함으로써 복잡도를 낮추는 방식으로 접근해 보는 것은 어떨까?

    Session session = ...
    List<Student> students = ...
    Enrollment enrollment = session.enrollment(students);
    Student student = enrollment.enroll(user);
    enrollmentRepository.save(student.getUserId(), student.getSessionId());

위 코드에서 리팩터링 힌트를 얻을 수 있는 부분이 있다면 리팩터링해 본다.
위 코드에서 Student는 은정님 구현한 코드의 Registration과 같음

[javajigi]

Entity 객체를 생성하고 있는데 Repository에서 사용하는 이유는?

Suggested change

	Session session = sessionRepository.findById(payment.getSessionId());
	session.validateEnroll(payment.getAmount());
	Registration registration = new Registration(payment.getSessionId(), payment.getNsUserId());
	registrationRepository.save(registration);
	SessionEntity session = sessionRepository.findById(payment.getSessionId());
	List<Registration> registrations = registrationRepository.findBySessionId(payment.getSessionId());
	Enrollment enrollment = session.enrollment(registrations);
	enrollment.enroll(payment);

위와 같이 Repository에 값을 전달하고 조회할 때 Entity를 사용하는 것은 어떻게 생각하나?

[Eundms]

(바꿔야지 하고 잊어버렸습니다)
SessionRepository는 도메인 레이어에 있으므로 Session으로 받는게 맞는 거 같고
구현체는 인프라 레이어에 있으므로 SessionEntity를 사용하게 하려고 합니다

[javajigi]

피드백 반영 넘 잘 했네요. 💯
추가로 한번 고민해 봤으면 하는 부분이 있어 피드백 남겼으니 이번 기회에 한번 고민해 보면 좋겠습니다.

[javajigi]

Session으로 의존 관계를 가지다보니 Enrollment 생성에도 어려움이 있을 것 같다.
의존 관계를 끊고, 'long sessionId'만 전달하는 것은 어떨까?
객체의 의존 관계를 무조건으로 가져가는 것이 좋은 것은 아니기 때문에 이번 기회에 어느 시점에 의존 관계를 끊는 것이 좋을지 고민해 보는 연습도 해보면 좋겠다.