search

sopt-makers / sopt-auth-backend

3 stars 0 forks source link

[FEAT/#9] 도메인 모델 구현 #10

Closed hyunw9 closed 1 week ago

hyunw9 commented 2 weeks ago

Related Issue 🚀

Work Description ✏️

논의헀던 사항대로, User 객체 안에 여러 멤버들을 포함하는 구조로 작성했습니다. 각 멤버들은 모두 불변객체로서, 수정이 일어날 경우 필드를 직접 수정하는 것이 아닌, 수정된 객체를 반환하는 형식으로 구현하고자 합니다.

또한 프로젝트에서 중요하다고 생각되는 도메인 모델이기 때문에,, 가볍게 테스트 주도 개발을 한번 해보았습니다. 이렇게 하는게 맞는지..

PR Point 📸

다음은 구현 단계에서 제가 개인적으로 생각한 제약조건 및 검증입니다. 틀린 부분이 있을 수 있습니다.

Activity

https://github.com/sopt-makers/sopt-auth-backend/blob/77ef5e0472a4fd2f571c9a0ae32d806f6c23984d/domain/src/main/java/sopt/makers/authentication/user/Activity.java#L33-L40

TEAM 은 없을 수 있지만, PART, ROLE, Generation이 Null일 수 없기 때문에, 검증로직을 추가했습니다.

ActivityList

https://github.com/sopt-makers/sopt-auth-backend/blob/77ef5e0472a4fd2f571c9a0ae32d806f6c23984d/domain/src/main/java/sopt/makers/authentication/user/ActivityList.java#L32-L40

유저는 여러 활동을 할 수 있지만, 중복된 활동 정보는 존재할 수 없기 때문에 중복 검사를 진행합니다. O(N) 탐색입니다.

https://github.com/sopt-makers/sopt-auth-backend/blob/77ef5e0472a4fd2f571c9a0ae32d806f6c23984d/domain/src/main/java/sopt/makers/authentication/user/ActivityList.java#L42-L47

Activity에서는 활동 내용들을 검증한다면, ActivityList는 Activity 자체가 Null인지 검증합니다. 당연히 Input으로 들어오는 Activity는 Null일 수 없기 때문에, IllegalArgExption을 반환합니다.

Auth Platform

https://github.com/sopt-makers/sopt-auth-backend/blob/77ef5e0472a4fd2f571c9a0ae32d806f6c23984d/domain/src/main/java/sopt/makers/authentication/user/AuthPlatform.java#L5-L15

사용자는 Enum에 직접접근이 어렵기 때문에, String 형을 입력으로 받아 Enum을 반환하는 로직을 작성했습니다. e.g. client ("GOOGLE") 요청 -> server는 Enum.Google 반환

위 방식은 검색이 필요한 Enum에 대부분 적용했습니다.

SocialAccount

https://github.com/sopt-makers/sopt-auth-backend/blob/77ef5e0472a4fd2f571c9a0ae32d806f6c23984d/domain/src/main/java/sopt/makers/authentication/user/SocialAccount.java#L22-L26

SocialAccount 검색을 위해 들어오는 문자열이 Null이거나 비어있을 경우, 예외를 반환합니다.

현재 반환하는 IllegalArgumentException은, 추후에 다른 예외로 전환이 가능합니다. 리뷰 부탁드립니다.. 굽신굽신

height[bot] commented 2 weeks ago

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

yummygyudon commented 2 weeks ago

궁금한 점 몇 가지 남깁니다!! (한 번에 꼼꼼히 드리지 못하고 나눠서 여러 번 드리게 된 점 양해 부탁드립니다...!!)


  1. 내부 field에 Wrapper 클래스를 사용하는 이유

몇 몇 VO 내부에서 기본형 타입인 int나 long이 아닌 Integer와 Long을 사용하는 걸 확인했습니다. null 처리하는 것에 있어 이점이 있어 Entity 등에서 요긴하게 쓰이는 타입이지만 기본적으로 저장 용량 낭비 및 연산하는 데에 있어 어려움(unboxing 후에 가능)이 존재한다는 특징이 있습니다.

불변 객체이며 VO이기 때문에 해당하는 대부분의 필드들은 not null이 보장되어야 할텐데 기본형 타입이 아닌 Wrapper 클래스를 사용하신 이유가 궁금해요!


  1. Test 시, given 용도의 Dummy Data를 ParameterizedTest로 수행하지 않고 직접 객체를 만든 이유

모든 테스트 메서드 내에서 given 값에 대해 구성 요소들을 순차적으로 생성하는 로직이 작성되어 있는 것 같아요!

물론 객체 생성 프로세스를 명시하는 부분에서 좋을 순 있겠지만 테스트의 목적은 Dummy Data를 만드는 과정을 검증하는 것이 아닌 비교군과 기대군 간의 검증이 목적이기 때문에 자칫 가독성과 반복적인 코드 중복으로 자원 낭비가 될 . 수있다고 생각합니다.

또한 여러 메서드에서 반복되어 사용하는 데이터라면 한 번만 정의해서 재사용할 수있다는 장점도 가져갈 수 있을 것같습니다!!

여러가지 JUnit에서 지원하는 기능을 맘껏 활용해보는 것은 어떨까요?!


우선 요종도까지인 것 같습니다!! 감사합니다! 😊

hyunw9 commented 2 weeks ago

또한 도메인 객체 모두를 너무 불변성을 보장하려다 자칫 유연성이 저해될까 걱정이 되기도 하네요!! 몇 몇 필드들은 가변성이 짙은 요소들인 것 같아서요!!

근데 저도 이 부분 동의합니다. 유연함을 가져가는게 좋을 것 같아요