Feature/create user #38

sm9171 · 2023-10-01T16:21:27Z

#31

📌 요약

user 도메인 생성
- UserReader, UserWriter, User
user api 작성
- createUser(유저 생성) , getUser(유저 조회)
user test 작성
- UserTest, UserRepositoryTest, UserServiceTest

📕 무엇을 작업하셨나요?

📖 변경사항

logback-test.xml 추가
application.yml 수정
build.gradle에 ktlint 플러그인 추가

✅ 체크리스트

환경변수를 임의로 수정하지 않았나요?
불필요한 로그를 지우셨나요?

- user 도메인 계층, 응용 계층, 표현 계층 생성 - createUser, getUser 엔드 포인트 생성

- name, email, address 필드 유무 체크 - user 객체 단위 테스트 작성

github-actions · 2023-10-01T16:23:52Z

Test Results

0 tests 0 ✔️ 0s ⏱️
0 suites 0 💤
0 files 0 ❌

Results for commit 333b360.

♻️ This comment has been updated with latest results.

- 기본 프로파일 일때 logging.xml import 제외

github-actions · 2023-10-02T05:01:25Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

github-actions · 2023-10-02T06:35:18Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

github-actions · 2023-10-02T14:12:38Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

e-build

수고하셨습니다.

e-build · 2023-10-03T01:52:54Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/application/UserService.kt

+    private val userWriter: UserWriter,
+) {
+
+    fun createUser(request: CreateUserRequest): CreateUserResponse {


회원가입 로직으로 보이는데, 간단하게 중복검사 로직정도 추가하는 건 어떠신가요?

또한 실제 커머스라고 한다면 구매자와 판매자는 회원가입 과정에서 서로 다르게 요구사항이 발전하게 될 것 같습니다. User 도메인 모델을 하나로 쓰기로 논의했지만, API 와 서비스 레이어는 분리해서 정의하는 건 어떠신가요?

예를 들어, 구매자와 판매자는 회원가입 과정에서 다음과 같이 다를 수 있을 것다고 생각합니다.

구매자 - 장바구니 추가, 구매자 등급 부여, 회원가입 축하 쿠폰 부여 등

판매자 - 상점 추가 및 연결, 판매자 권한 부여 등

확장성 면에서 서비스 레이어부터 두 개로 나눠서 관리하는게 좋을것 같네요

e-build · 2023-10-03T02:04:30Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/domain/User.kt

+    init {
+        if (name.isBlank()) {
+            throw IllegalArgumentException("이름은 비어 있을 수 없습니다")
+        }
+        if (email.isBlank()) {
+            throw IllegalArgumentException("이메일은 비어 있을 수 없습니다")
+        }
+        if (address.isBlank()) {
+            throw IllegalArgumentException("주소는 비어 있을 수 없습니다")
+        }
+    }


프로퍼티들에 대한 유효성 검사 로직을 User 도메인 모델 안에 정의함으로써 응집도를 높일 수 있는 것 같아 좋은 것 같습니다.

e-build · 2023-10-03T02:16:12Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/domain/User.kt

+    val email: String,
+    val address: String,
+    val userType: UserType,
+    var id: Long? = null,


id 를 var와 Nullable 타입으로 선언하신 이유가 궁금합니다! id는 Null을 허용하지 않고 재할당될 수 없는 프로퍼티라고 생각합니다.
UUID 혹은 ULID를 활용하면 DB의 시퀀스나 auto-increment를 사용하지않고 객체 생성 시점에 ID에 값을 할당할 수 있습니다.

말씀해주신대로 값 변경이 안되도록 val 타입을 사용하는게 맞는것 같습니다. id값을 UUID로 사용하면 nullable 타입으로 사용안해도 괜찮을 것 같네요

e-build · 2023-10-03T02:44:58Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/application/UserService.kt

UserService 라는 네이밍에 대해 고민해볼 필요가 있을 것 같습니다. UserService라는 이름은 책임의 범위가 넓고 모호하게 느껴지는 것 같습니다.

네 특징 별로 구분하는것이 좋을것 같네요

e-build · 2023-10-03T03:03:48Z

commerce-infra/db-main/src/main/kotlin/com/hanghae/commerce/data/domain/UserEntity.kt

-        protected set
+    var id: Long? = null,
+) {
+    companion object {


Entity 와 Domain 모델 간의 변환에 있어서 공통된 컨벤션이 필요할 것 같습니다.
Entity Model -> Domain Model 변환하는 로직을 정적 팩토리 함수로 정의해주신 대로 결정해도 괜찮을 것 같습니다.
정적 팩토리 함수에 대한 네이밍을 고민해볼 수 있을 것 같은데, 이펙티브 코틀린에서 제시하는 다음과 같은 방법들은 어떠신가요?

https://bin-repository.tistory.com/162

https://kyucumber.github.io/posts/book/effective-kotlin/effective-kotlin-item-33

네 이펙티브 코틀린에서 제시한 메소드명 컨밴션을 참고하면 좋을것 같네요 😄

e-build · 2023-10-03T03:05:22Z

commerce-infra/db-main/src/main/kotlin/com/hanghae/commerce/data/domain/UserEntityRepository.kt

+            User(
+                id = it.id!!,
+                name = it.name!!,
+                email = it.email!!,
+                address = it.address!!,
+                age = it.age,
+                userType = it.userType,
+            )


마찬가지로 UserEntity -> User 로 변환하는 정적 팩토리 함수를 정의해서 활용할 수 있을 것 같습니다!

e-build · 2023-10-03T03:29:27Z

commerce-api/src/main/resources/application-develop.yml

spring.config.import=logging.yml 구문은 공통적으로 application.yml 파일에 적용할 수 있을 것 같은데 옮기신 이유가 있을까요???

logging.xml에서 환경변수 ${spring.profiles.active}값을 가져오는데 ci서버에서 test를 진행할 때 이 환경변수 값이 없어서 에러가 발생하여서 application.yml에 logging.yml을 제외하고 다른 프로파일 application.yml에만 추가하였습니다.

KATEKEITH

수고하셨습니다 ~ : )

KATEKEITH · 2023-10-03T13:23:34Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/presentation/dto/CreateUserRequest.kt

+
+import com.hanghae.commerce.user.domain.UserType
+
+data class CreateUserRequest(


DTO에서는 유효성 검사가 필요없을까요?

일단 도메인에만 유효성 검사를 추가하였는데 DTO단에서도 유효성 검사가 필요할 것 같네요 😄

KATEKEITH · 2023-10-03T13:28:03Z

commerce-infra/db-main/src/main/kotlin/com/hanghae/commerce/data/domain/UserEntity.kt


 @Entity
+@Table(name = "users")
 class UserEntity(


UserEntity는 equals, hashcode를 override할 필요가 없을까요?

네 equals, hashcode메소드를 override할 필요가 있을것 같습니다

KATEKEITH · 2023-10-03T13:36:58Z

commerce-api/src/main/kotlin/com/hanghae/commerce/user/application/UserService.kt

+import org.springframework.stereotype.Service
+
+@Service
+class UserService(


application layer는 어떤 역할을 하고 Service를 해당 layer에 둔 이유는 무엇일까요?

저는 응용계층을 표현계층에 최종적으로 보여주는 데이터를 만들어주는 계층으로 보고 있습니다. 그래서 UserService를 응용서비스 클래스로 보고 응용계층에 배치를 하게 된 것 같습니다. 혹시 은지님은 다른 관점에서 UserService클래스를 바라보셨을까요??

github-actions · 2023-10-04T04:39:15Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

- User.createUser -> User.of - UserEntity.toEntity -> userEntity.from

github-actions · 2023-10-04T05:55:17Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

github-actions · 2023-10-05T04:49:46Z

📝 테스트 커버리지 리포트입니다

Overall Project	NaN% `NaN%`	🟢

There is no coverage information present for the Files changed

sm9171 added 5 commits October 1, 2023 16:28

feat(User): user 생성, user 조회 기능 구현

d607c48

- user 도메인 계층, 응용 계층, 표현 계층 생성 - createUser, getUser 엔드 포인트 생성

test(User): UserRepository, UserService, User 테스트 구현

faecbe0

feat(User): user validate 체크

ade090e

- name, email, address 필드 유무 체크 - user 객체 단위 테스트 작성

feat(User): userType 필드 추가

c0aed98

chore: logback-test.xml 추가

bb16061

sm9171 added the enhancement New feature or request label Oct 1, 2023

sm9171 added this to the TDD 1주차 milestone Oct 1, 2023

sm9171 requested review from 5Hanui, KATEKEITH and e-build October 1, 2023 16:21

sm9171 self-assigned this Oct 1, 2023

sm9171 added 2 commits October 2, 2023 13:54

chore: api application.yml 설정파일 수정

79ca470

- 기본 프로파일 일때 logging.xml import 제외

test(user): save 테스트 코드 변경

1405032

style: ktlint plugin추가 및 코드 스타일 수정

587362b

feat(user): transactional 추가

96d321d

e-build suggested changes Oct 3, 2023

View reviewed changes

e-build reviewed Oct 3, 2023

View reviewed changes

KATEKEITH reviewed Oct 3, 2023

View reviewed changes

feat(user): CreateUserRequest validation 기능 추가

28599f2

refactor(user): 정적팩토리메소드명 변경

e3d84d6

- User.createUser -> User.of - UserEntity.toEntity -> userEntity.from

refactor(user): application, presentation레이어에서 판매자, 구매자로 유저 분리

333b360

e-build merged commit 46ef314 into develop Oct 5, 2023
6 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/create user #38

Feature/create user #38

sm9171 commented Oct 1, 2023 •

edited

Loading

github-actions bot commented Oct 1, 2023 •

edited

Loading

github-actions bot commented Oct 2, 2023

github-actions bot commented Oct 2, 2023

github-actions bot commented Oct 2, 2023

e-build left a comment

e-build Oct 3, 2023

sm9171 Oct 3, 2023

e-build Oct 3, 2023

e-build Oct 3, 2023

sm9171 Oct 3, 2023

e-build Oct 3, 2023

sm9171 Oct 3, 2023

e-build Oct 3, 2023

sm9171 Oct 3, 2023

e-build Oct 3, 2023

e-build Oct 3, 2023

sm9171 Oct 3, 2023

KATEKEITH left a comment

KATEKEITH Oct 3, 2023

sm9171 Oct 3, 2023

KATEKEITH Oct 3, 2023

sm9171 Oct 3, 2023

KATEKEITH Oct 3, 2023

sm9171 Oct 3, 2023

github-actions bot commented Oct 4, 2023

github-actions bot commented Oct 4, 2023

github-actions bot commented Oct 5, 2023


		import com.hanghae.commerce.user.domain.UserType

		data class CreateUserRequest(

Feature/create user #38

Feature/create user #38

Conversation

sm9171 commented Oct 1, 2023 • edited Loading

📌 요약

📕 무엇을 작업하셨나요?

📖 변경사항

✅ 체크리스트

github-actions bot commented Oct 1, 2023 • edited Loading

Test Results

github-actions bot commented Oct 2, 2023

📝 테스트 커버리지 리포트입니다

github-actions bot commented Oct 2, 2023

📝 테스트 커버리지 리포트입니다

github-actions bot commented Oct 2, 2023

📝 테스트 커버리지 리포트입니다

e-build left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KATEKEITH left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Oct 4, 2023

📝 테스트 커버리지 리포트입니다

github-actions bot commented Oct 4, 2023

📝 테스트 커버리지 리포트입니다

github-actions bot commented Oct 5, 2023

📝 테스트 커버리지 리포트입니다

sm9171 commented Oct 1, 2023 •

edited

Loading

github-actions bot commented Oct 1, 2023 •

edited

Loading