f-lab-edu / infrun Goto Github PK

목표

Member 표현 계층을 코틀린으로 변환한다

목표

Member 도메인의 코드를 다른 코드와 일관성을 맞추고 개선한다.

할 일

• #69
• #71
• #73

목표

Member application 계층을 Kotlin으로 변환한다.

할 일

• Application 레이어 Kotlin 변환
• Member.java -> MemberKt.kt 로 변경
• Member.java를 제거하고 MemberKt를 Member.kt로 변경

목표

유저는 장바구니에 추가한 강의 중 하나 이상을 선택하여 주문을 생성할 수 있다

할 일

• 장바구니에 없는 강의인 경우 예외가 발생한다
• 유저는 사용가능한 쿠폰을 적용할 수 있다
• 생성된 주문 정보에는 주문 상태, 주문 일자, 주문한 강의 정보, 총 결제 금액, 할인 금액이 있어야 한다

목표

File Storage 저장 방식을 Object Storage 저장 방식으로 변경한다.

할 일

• Upload Id 발급
• PreSigned URL 발급
• Upload Complete 요청

고려사항

• 업로드 완료 시 event 방식의 강의 정보 업로드

목표

유저는 선택한 강의를 구매할 수 있다.

ToDo

• #47
• #50
  • 결제 중간에 취소 또는 실패 시 쿠폰은 미적용 상태가 되어야 한다

고려사항

• 결제 모듈은 무엇을 적용할까?
• 결제 중에 발생할 수 있는 이슈는 뭐가 있을까?
• 결제 프로세스 중 실패할 경우 주문 정보는 어떻게 해야할까?

목표

Git Merge 정책 제안

고려사항

Feat -> Develop Merge할 때 Squash & Merge 방식으로 정하는 것이 괜찮을 것 같습니다.

Feat 브랜치는 기능 구현을 위한 브랜치이며 해당 기능의 세세한 작업 사항은 PR에서 확인할 수 있고
실제 Develop 브랜치에서는 해당 기능 구현을 하나의 커밋으로 묶어 관리할 수 있습니다.

Develop 브랜치 운용 중에 문제가 발생하면 feat 브랜치 커밋 내역을 기준으로 reset 시켜 확인할 수 있는 것이 더 용이할 것 같습니다.

참고자료

https://meetup.nhncloud.com/posts/122

• MemberController의 반환값 수정
• MockMvc로 변경하여 표현 계층만 슬라이스 테스트 수행
• 코드 리팩토링

목표

사용자는 본인의 쿠폰을 조회할 수 있다.

할 일

• 쿠폰 조회 기능 구현
• 쿠폰 도메인 로직 수정
• 코드 리팩토링

• MemberProcessor 객체를 각 역할만 수행하도록 나누기
• Mocking 테스트를 IntegrationTest로 변경하기
• 코드 개선하기

목표

Lecture Domain Test Code 정상화

할 일

• Lecture Domain Test Code ALL PASS

목표

강의 등록 기능을 구현한다.

ToDo

• 강의는 강의명과 강의 자료, 강의 가격과 챕터, 강의 영상들을 업로드한다
• 강의 영상은 multipart로 여러 영상들을 동시에 업로드
• 강의 등록 성공 시 201 Created 반환

고려사항

• 영상 포맷
• 대용량 데이터 처리

목표

강의 등록시 Role을 체크하여 강사가 아닌 경우 excpetion 발생

할 일

• 강의 등록 Controller 에서 Role 체크

고려사항

• Spring Security 인증/인가 FilterChain, hasRole

목표

Lecture Domain Refactoring

할 일

• ManyToOne fetch Type EAGER(기본값) to LAZY
• Lecture Process Transactional

목표

강의 등록 시 Role을 확인하고 Teacher 가 아닌 경우 Exception 처리

고려사항

1. Member Facade 에게 메세지
2. Member Facade의 역할의 범위?

• Member Role을 반환해주는 것 까지
• Member Role이 Teacher인지 체크 해주고 exception을 발생시키는 isTeacher을 수행 -> domain에서는 teacher 여부만 체크

3. Lecture 내부에서 Member resource로의 직접적인 접근은 지양

결론 : Member Facade의 책임을 어디까지 책정할 것인가 ?

목표

request Validation Message 를 처리할 template 을 작성하고 상수로 처리한다.

할 일

• request Validation Message 를 생성한다.
• request Validate 에 적용한다

목표

LectureCommandProcessor를 기능 별로 분리하여 가독성을 높인다.

할 일

• Lecture, LectureReview 별 클래스 작성
• Register, Update, Delete 별 클래스 작성
• Test Code 동일하게 분리하여 구조 변경

고려사항

• 분리 Level 을 Lecture, LectureReview 등 도메인 별로 작성할 것인가?
• Register, Update, Delete 등 행위별 작성을 추가할 것인가
• LectureReview에 대한 도메인을 Review 도메인으로 별개로 작성?

목표

유저는 구매한 강의를 환불 할 수 있다.

ToDo

• 모든 강의에 대한 조건 없는 100% 환불
• 한번에 하나의 강의만 환불 가능

고려사항

• 환불 정책에 따른 환불 가능 여부 고려

목표

쿠폰 발급 기능

ToDo

• 강사는 쿠폰 개수와 유효기간, 할인율을 설정 후 발급
• 쿠폰은 유효기간, 시리얼 넘버, 할인율, 상태를 가짐
  • 상태는 등록 여부, 사용 여부 상태로 나뉨

목표

유저는 구매한 강의에 리뷰를 남길 수 있다.

ToDo

• 유저는 강의에 리뷰를 남길 수 있다.
• 유저는 남긴 리뷰를 수정 할 수 있다.
• 유저는 남긴 리뷰를 삭제 할 수 있다.

고려사항

• 답글 기능

목표

Querydsl 설정을 추가한다.

할 일

• build.gradle 수정
  • Querydsl 생성 위치 설정
  • gradle clean 시 QClass 디렉토리 삭제
• build 시 생기는 generate 디렉토리 .gitignore 추가

목표

강사는 본인 강의에 대한 소개글을 작성할 수 있다.

할 일

• 소개글을 DB에 그대로 저장한다

고려사항

• 성능 개선을 위한 file 영속화 및 문서화 고려

목표

쿠폰 등록 기능 구현

ToDo

• 회원이 쿠폰의 시리얼 넘버를 입력
• 쿠폰이 등록 가능하면 200 OK 반환
• 쿠폰이 등록 불가능하면 400 Bad Request 반환

고려사항

• 동시성 문제가 발생할 여지가 있음

목표

Lecture Repository Package 오류 수정

할 일

• Lecture Repository 및 Develop branch 충돌 해결

목표

유저는 강의를 검색 할 수 있다.

ToDo

• Like 검색 허용
• 강의명으로 검색
• 강사명으로 검색

고려사항

• 등록 일 기준 검색 기능 필요 여부

목표

CI/CD 환경 구축

ToDo

• Github Action workflow 작성
• 클라우드 서비스에 웹 어플리케이션 배포
• 도커로 Spring 애플리케이션과 MySQL 컨테이너 환경 구성

고려사항

• 클라우드 환경 선정하기

목표

유저는 강의를 장바구니에 저장하거나, 저장된 강의를 제거할 수 있다.

ToDo

• 장바구니 강의 저장 기능
• 장바구니 강의 삭제 기능
• 체크된 강의 총 금액 계산

고려사항

목표

CQRS로 분리한 Command 와 Query Processor의 이름 분할

고려사항

• 현재 Command 를 Processor 로 작성한 상태

1. CommandProcessor
2. QueryProcessor

로 명시적으로 커맨드 역할을 하는 프로세서/ 쿼리 역할을 하는 프로세서로 구분하는 방식 채택 제안

목표

의존 관계에 있는 엔티티 필드 변경에 의한 컴파일 에러를 해결하고 개선한다.

할 일

• Lecture 엔티티 필드에 맞게 ID 대신 Member 객체를 사용하도록 변경
• 코드 개선

목표

develop branch hotfix

할 일

• 누락된 import 해결

목표

강의 상세와 등록되는 실제 파일을 매핑한다.

질문사항

request 처리 시 multipart 형태의 file 자체에 강의 상세 정보를 매핑 할 수 없음
-> 따라서 강의 상세 Json에 어떤 file이 매핑되어야 하는지 매핑해야하는데
-> file명으로 매핑하는 방식 채택

1. file을 저장
2. 저장된 file List를 반복문을 통해 파일상세의 fileName과 매핑
3. 이름을 찾아 id를 매핑
4. 파일상세 저장 시 이름에 매핑된 file Id 를 찾아 같이 저장

이 과정이 일어나기 위해서는 파일명이 중복되지 않아야 함

여기서 의문점 발생

Q. 이 파일명 중복 체크가 과연 필요한 행위인가?에 대한 의문
(상세를 매핑하기 위해 억지로 중복체크를 하는것이 아닌가 라는 생각이 문득 듦)

고려해본 방법

• multipart file 자체의 UUID 를 부착하여 저장 (의견)
• multipart file 자체의 식별자 존재여부 (실패)
• 강의-강의상세-파일 이 구조에서 동일한 강의 내부의 파일명 중복은 일어나도 문제 없는 구조

목표

Member 도메인 계층을 Kotlin으로 변경한다.

할 일

• Member domain 내의 자바 클래스들을 Kotlin 파일로 변경

목표

DefaultHandlerExceptionResolver 의 기본 Exception처리 Response

상황

1. Request 요청의 int 형식 데이터 존재
2. 해당 데이터를 String 형태로 착오 입력
3. 내부적으로 HttpMessageNotReadableException 발생
4. 응답 ErrorCdoe : UN_AUTHORIZATION로 유효하지 않은 인증 정보 Response

해결방안

• Spring Security 내부 동작 방식 확인 필요

목표

TestCode의 Repository Stub을 공통화 하여 재사용성을 높인다.

고려사항

Lecture Review를 등록하는 과정에서 Member와 Lecture에 대한 정보를 가져오는 작업이 필요합니다.

그래서 단위 테스트를 위한 Repository Stub 클래스가 필요한데
이미 시안님이 작성한 MemberRepository에 대한 Stub이 이미 있는 것을 토대로

각 도메인의 Repository Stub을 공통으로 추출하여 재사용성을 높이는 방법은 어떨까요?

목표

Lecture Repository Package 오류 수정

할 일

• Lecture Repository 및 Develop branch 충돌 해결

목표

현재 프로젝트에서 Kotlin을 사용할 수 있도록 환경을 설정한다

할 일

• build.gradle 수정
• 사용 중인 의존성을 Kotlin 적용 가능하도록 설정

• Member 엔티티 수정
• MemberRepository 수정
• 테스트 코드 수정

목표

회원 로그인 기능

ToDo

• 회원 로그인 Email, 비밀번호 필수 입력
• 로그인 요청 시 Email, 비밀번호 검증
• 비밀번호는 암호화를 적용하여 대조
• 로그인 실패 시 401 Unauthorized 예외 반환
• 로그인 성공 시 200 OK 반환

고려사항

• JWT, 세션?
• Spring Security 도입 고려
• 암호화 기능

목표

강의 업로드에 실패하는 경우를 확인하고 해결한다.

할 일

• 강의 상세에 대한 챕터-상세명 중복 확인
• 업로드 파일에 대한 챕터-파일명 중복 확인

고려사항

• 강의 명 자체에 대한 중복 처리가 필요한지?
• 파일에 대한 접근과 책임이 현재 Client에 있기 때문에 파일에 대한 Validating(확장자, 용량)은 Client의 책임 -> 추후 서비스 환경에서 영상에 대한 적합성 테스트 및 영상처리에 대한 작업이 필요한 경우 다시 Server로 책임 변경

목표

유저는 생성된 주문을 결제할 수 있다

할 일

• 결제 모듈 설정
• 결제 테스트 작성
• 주문 상태 변경

고려사항

• 결제 시 발생할 수 있는 이슈는 뭐가 있을까
• 결제 모듈의 통합 테스트 방법

목표

강의 등록시 멤버 Role Check에 대한 Unit Testing

현재상황

1. @PreAuthorize("hasRole('ROLE_TEACHER')") 을 통해 권한을 부여
2. Postman으로 Member 등록 후 h2 database 직접 수정하여 Role TEACHER 로 변경
3. login 하여 Token 반환
4. 해당 Token을 Header의 Authorization에 Bearer prefix를 사용하여 요청 처리
5. 권한 직접 테스트 완료

이 상황에서 유닛 테스팅을 위한 작업을 동일하게 진행하려 하였으나
Member 객체의 Role을 코드 내부에서 컨트롤 할 수 있는 방법이 없어서 고민중입니다.

이렇게 flow 처리 방식이 아닌 Spring Security + JWT 자체적인 Testing 방법이나 다른 더 나은 방법이 있다면 공유 부탁드립니다!

목표

공통으로 사용될 커스텀 예외와 응답 객체를 정의한다

할 일

• 커스텀 예외 작성
• 공통 에러 코드 작성
• 응답 객체 작성

목표

회원 가입 기능

ToDo

• 회원가입 시 Email, 비밀번호, 닉네임을 입력
• Email과 닉네임 중복 확인
  • 중복이 있으면 404 Bad Request 반환
• 비밀번호 암호화 적용
• 회원가입 성공 시 201 Created 반환

고려사항

• 암호화 알고리즘

목표

역할 변경 후에 (USER -> TEACHER) @PreAuthorize("hasRole('TEACHER')") 메서드 호출 시 403 에러 코드가 발생하는 문제 해결하기.

현재상황

역할이 변경되어도, Jwt에 저장된 ROLE이 변경되지 않아 403 에러가 발생하는 문제가 있습니다.
이 문제를 해결하기 위해 제가 생각한 해결 방안은 다음과 같습니다.

1. 강사용 회원가입을 분리한다
2. 회원에서 강사로 역할 변경 시 재로그인이 되도록 로그아웃 처리를 한다

다른 의견이 있으시다면 주시면 감사하겠습니다.
의견이 수렴되면 해당 작업 들어가겠습니다! 🫡