woowacourse-teams / 2024-corea

코드리뷰 매칭 플랫폼, CoReA
https://code-review-area.com/
13 stars 7 forks source link

[BE] 피드백 서비스 리팩터링(#619) #635

Closed github-actions[bot] closed 2 days ago

github-actions[bot] commented 4 days ago

📌 관련 이슈

✨ PR 세부 내용

소셜 피드백 서비스를 리팩터링했습니다!

기본적으로 개발 피드백 서비스와 형식을 똑같이 하고, Reader, Writer를 분리하였습니다.

github-actions[bot] commented 4 days ago

Test Results

 57 files   57 suites   9s :stopwatch: 178 tests 174 :white_check_mark: 4 :zzz: 0 :x: 185 runs  181 :white_check_mark: 4 :zzz: 0 :x:

Results for commit bef41469.

:recycle: This comment has been updated with latest results.

jcoding-play commented 2 days ago

모든 Reader/Writer 가 update , create 구문이 있을 때 Mapper 를 만들어야 하는가? 에 대해서, 다소 부정적인 의견도 듭니다. 어차피, 재사용이 없고 중간 변환 단계만 하는데 필요한가? 라는 생각 떄문인데요. 방장이 참여를 하는 것과 사용자가 참여를 한다. 이렇게 두 가지가 있을 때 공통된 입력으로 변환하는건 괜찮은거 같으나 1:1 인데 변환은 굳이 인거 같습니다.

이 부분은 약간 트레이드 오프인듯 해요~! 조이썬 말대로 재사용이 없다면 변환 단계가 필요 없겠지만, 추후 비즈니스 요구 사항이 추가되어 도메인 필드가 추가된다면 도메인 계층의 dto만 수정해도 되기 때문에 장점도 있겠죠. 그리고 클라이언트가 요청/응답받는 dto를 도메인 계층까지 내리는게 어색하기도 해서 다음과 같은 변환 과정을 두었는데, 이 부분은 사실 저도 상당히 귀찮았기 때문에 저번에 pr에 이에 대한 의견을 물어본것이구요~! 이 부분에 대해서 같이 얘기하고 맞쳐보면 하네요~! 일단은 이번 pr에서는 유지해봅니당~ 😀