-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
점주 회원가입 #12
The head ref may contain hidden characters: "feature/6_Dr-KoKo_\uC810\uC8FC_\uD68C\uC6D0\uAC00\uC785"
점주 회원가입 #12
Conversation
제약조건 설정 및 검증 로직 구현
Order가 예약어이기 때문에 테이블 이름 변경
개행문자를 space에서 tab으로 변경
`~` show-sql: 실행되는 sql 조회 `~` generate-ddl: 테스트시 테이블 자동 생성 `~` ddl-auto: 어플리케이션 생성시 생성, 종료시 삭제 `~` open-in-view: 의도하지 않은 조회 쿼리 발생 방지
`+` SignUpVendorCommand: 서비스 호출을 위한 command `+` NoOpPasswordEncoder: 아무런 기능을 제공하지 않는 PasswordEncoder `+` DuplicateException(및 DuplicateEmailException): unique 제약조건에 부합하지 않을 때 발생하는 예외 `+` InvalidCreationException: 기타 제약조건에 부합하지 않는 경우 발생하는 예외
`+` AuthController: "/auth" 컨텍스트 처리 `+` ApiResponse: 공통 응답처리를 위한 모델 `+` ErrorCode: 공통 예외처리를 위한 코드 `+` SignUpVendorRequest: POST /auth/vendor 요청을 받는 dto
Vendor 생성시 검증로직 테스트 코드 작성
`+` 성공시 DB에 저장 `+` 동일한 이메일 존재시 예외 발생
`+` 성공시 vendorReposity/payAccountRepository의 save 호출 `+` 실패시 DuplicateEmailException 발생
`~` /auth/vendors -> /vendors `~` 예외처리 rfc7807에 부합하게 변경
전화번호를 검증하기 위한 어노테이션 및 커스텀 Validator 구현
`+` 판매자 회원가입 테스트
전반적으로 CheckedException을 이용해서 구현하셨는데 구체적인 이유가 궁금합니다 :) |
예외에는 1) 그런데 서비스 또는 도메인에서 따라서 저는 서비스/도메인에서는 (특히 변경이 자주 일어나는 프로젝트에서) |
저는 이 부분에 대해서 살짝 다른 관점입니다! 먼저 저는 예외 상황에 대해 그래서 해당 관점에서 보게 된다면
이 부분에서도 토론해 보면 좋을 거 같네요 :) |
좋습니다. 더 자세한 논의는 #14 에서 진행하도록 하겠습니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
사담: 점주랑 구매자 회원가입이 거의 동일하게 구현되어서 동훤님 코드 많이 참고했습니다..ㅎㅎ
그리고 제가 동훤님 커밋을 가져와야할 부분이 많았어서 저 작은 단위로 커밋해주시면 좋을 것 같아요
PayAccount Repository 같은 같이 사용하는 부분은 그냥 동훤님 commit cherry pick 해서 가져올라 했거든여
그리고 예외 처리 방법에 대해서 논의 해보면 좋을 것 같네요!
src/main/java/camp/woowak/lab/web/dto/request/SignUpVendorRequest.java
Outdated
Show resolved
Hide resolved
`+` 패스워트 7/8글자 테스트 추가
패스워드는 8자 이상부터 허용한다.
src/main/java/camp/woowak/lab/web/dto/request/SignUpVendorRequest.java
Outdated
Show resolved
Hide resolved
파라미터가 오지 않은 경우 또는 비어있는 경우에 대한 검증 추가
파라미터가 오지 않은 경우 또는 비어있는 경우에 대한 테스트 추가
`-` 기존에 등록된 ExceptionHandler `~` 새로운 ExceptionHandler에 ResponseEntityExceptionHandler 상속
HttpStatusException을 상속하는 구조로 변경
검증 로직은 VendorValidator에서 수행
Exception 계층 수정으로 인한 테스트 코드 수정
서비스에서 UncheckedException을 던지게 수정
예외는 VendorApiControllerAdvice에서 처리
HttpStatusException을 상속받은 RuntimeException으로 변경
💡 다음 이슈를 해결했어요.
Issue Link - #6
💡 이슈를 처리하면서 추가된 코드가 있어요.
도메인(
Vendor
)Vendor를 생성할 때 검증로직을 통과해야합니다. 실패하면
InvalidCreationException
가 발생합니다.기타 도메인 변경
Order
생성 테이블 이름 변경 (Order -> Orders)서비스(
SignUpVendorService
)Vendor를 생성 및 DB에 저장하는 서비스 입니다.
Vendor는 모두 PayAccount를 필수적으로 가지고 있어야하므로 하나의 트랜젝션 내에서 PayAccount 및 Vendor를 생성합니다.
만약 신규 Vendor 저장을 (중복된 이메일 등의 이유로) 실패하면 롤백 됩니다.
컨트롤러(
VendorController
)서비스(또는 도메인)에서 발생한 예외를 받아서 사용자가 받을 수 있는 형태의 데이터로 가공합니다.
GlobalExceptionHandler
공통 예외를
RFC 7807
에 부합하게 처리하기 위해ResponseEntityExceptionHandler
를 상속받았습니다.ApiResponse
공통 응답을 위해 모델을 고안하였습니다. 구체적인 모델에 대해서는 추후 논의가 필요해보입니다. 따라서 Discussion탭에 논의사항으로 올리도록 하겠습니다. - #13
테스트
각각의 레이어(도메인,서비스,컨트롤러)에서 단위테스트를 진행하였습니다.
💡 이런 고민을 했어요.
💡 다음 자료를 참고하면 좋아요.
✅ 셀프 체크리스트