Step2 - 수강신청(도메인 모델) #820
Step2 - 수강신청(도메인 모델) #820
Conversation
- 패키지 분리
- Course TDD기반 유/무료 구분 행위개발
- Course에 BaseEntity 적용 - BaseEntity protected 타입 게터 생성
- Course, Cohort 생성자 및 예외처리 TDD 구현
- Cohort 설계 행위 일부분 TDD 구현
- Cohorts 도매인 객체 구현 - 특정 기수 식별자를 기반으로 특정 기수 조회 및 수강신청 가능여부 판단행위 Course에 구현
- 수강신청 비즈니스 로직 조합 및 부족한 도메인 로직 구현
- 방향성 주석 메모
javajigi
left a comment
javajigi
left a comment
There was a problem hiding this comment.
아직 미완성인 코드라 이미지 관련 부분은 없지만 핵심 로직에 집중하면서 미션 진행한 모습 👍
pr 본문에 남긴 것처럼 복잡도가 아주 높아진 상태는 아니라 생각해요.
지금 상태에서 요구사항 반영해 가면서 리팩터링 도전해 보면 충분히 괜찮은 설계로 구현 가능하다 생각합니다.
피드백 남겨봤으니 반영해 보면 좋겠습니다.
| import nextstep.common.domain.BaseEntity; | ||
| import nextstep.courses.cohort.domain.enumeration.CohortStateType; | ||
|
|
||
| public class Cohort extends BaseEntity { |
There was a problem hiding this comment.
Cohort 객체는 우리가 현장에서 흔하게 접하는 인스턴스 변수가 많은 객체의 모습이다.
객체 지향 생활 체조 원칙의 다음 두 가지 원칙에 지키기 위해 노력해 본다.
- 규칙 6: 모든 엔티티를 작게 유지한다.
- 규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
특히 규칙 7의 경우 지키기 힘들다 하더라도 인스턴스 변수의 수를 줄이기 위해 도전해 본다.
힌트: 상속을 통한 인스턴스 변수 줄이기, 관련 있는 인스턴스 변수를 새로운 객체로 분리하기 등 활용
|
|
||
| import java.time.LocalDateTime; | ||
|
|
||
| public class Period { |
|
|
||
| public class CourseDomainService { | ||
|
|
||
| public Enrollment registerEnrollment(Course course, Long cohortId, Long studentId) { |
There was a problem hiding this comment.
수강 신청을 Course를 통해 접근하기보다 cohortId에 해당하는 Cohort를 조회한 후 Cohort로 바로 접근하는 것은 어떨가?
| Course course = courseRepository.findById(request.getCourseId()) | ||
| .orElseThrow(NotFoundException::new); |
There was a problem hiding this comment.
앞에도 피드백했지만 Course보다 Cohort를 조회한 후 Cohort를 통해 수강 신청을 진행하면 어떨까?
| import nextstep.courses.cohort.domain.Cohort; | ||
| import nextstep.courses.cohort.domain.enumeration.CohortStateType; | ||
|
|
||
| public class CohortFixture { |
There was a problem hiding this comment.
이와 같이 Fixture를 두고 것도 좋은 접근 방법임
이외에도 다른 접근 방식이 있으니 본인만의 스타일을 찾아보면 좋겠음.
Cohort 객체와 같이 인스턴스 변수가 많은 객체를 테스트하려면 객체를 생성하는데 어려움이 있다.
중복 코드 또한 많이 발생해 Session을 생성할 때 생성자의 인자가 변경되는 경우 변경할 부분이 많아진다.
https://www.arhohuttunen.com/test-data-builders/ 문서 참고해 Cohort과 같이 복잡한 객체의 테스트 데이터를 생성할 때 어떤 방법을 사용할 것인지 선택해 보면 좋겠다.
이번 기회에 내가 선호하는 방법을 적용해 보고 앞으로도 쭈욱 활용하는 방식이면 좋겠다.
- 에그리커트 개념 제거로 수강신청 Cohort 기반으로 동작 - Course의 불필요 로직 제거
- 강의 이미지 관련 유효성검사 TDD 구현
- 기수 객체의 인스턴스 변수 최소화를 위해 기수학생관리 객체 생성 및 구현 - 강의 객체 기본 내용 구현
- 기수상태 객체를 통해 기수 객체 인스턴스 변수 최소화 - 기수상태 관련 요구사항 TDD 구현 및 불필요 코드 삭제 - 모집마감 상태 추가
- 기수상태를 체크해 모집마감 상태로 변경하는 도메인 서비스 로직 추가. - service의 udpate 쿼리 부분 course -> cohort로 변경
- 불필요 로직 삭제
2 participants
수강신청 - 도메인모델 중간 결과물입니다.
요구사항 해석과 현재 넥스트스텝 웹의 동작 및 도매인 모델 설계시 코스 - 강의 관계에서 코드 - 기수 - 강의 관계가 형성되야된다고 생각해 설계후 기능을 구현했는데요.
기능구현하다보니 요구사항과의 괴리감이 자꾸 생겨서요..
강의의 일부 기능과 타입들이 기수로 넘어가는게 많아지는것 같아 뭔가 의도하신 교육 방향을 크게 벗어나는게 아닌가.. 싶어서 미완성 결과물 먼저 공유드리고 피드백 받으려고 PR 드려요!
뭔가.. 장황하게 설계해놓으니 구현할때 복잡해지는 감이 있네요 ㅠㅠ
설계 및 구현하면서 코스에 대한 에그리거트를 기준으로 생각하다보니 더 어려웠던거 같습니다..