[BE] 쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 변경 + 리팩터링(#613)

[github-actions]

📌 관련 이슈

• closed : [BE] 쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 변경 + 리팩터링 #613

✨ PR 세부 내용

쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 수정하였습니다.

그리고 피드백 서비스 쪽에 대한 리팩터링 범위가 그리 크지 않을줄 알고 같이 작업을 했었는데,
생각보다 범위가 커서 일단 현재 작업한 부분까지만 PR 제출하고 나머지 피드백 서비스쪽 리팩터링 이어서 해볼게요.

현재 파일 변경 범위가 넓어 "쓴 피드백은 피드백 모아보기에서 바로 보기 기능"에 대한 변경 사항만 보고 싶으시다면
쓴 피드백 조회 기능 수정 여기를 통해 봐주세요.

---

P2: DTO 관리

Reader와 Writer의 역할을 분리하면서 RequestDto와 ResponseDto를 어디까지 전달할지 고민했고,
결국 Service 레이어를 넘어가지 않도록 하는 게 좋겠다고 판단했습니다.

그래서 어제 조이썬과 논의한 결과, Service와 Domain 간의 데이터 전송을 위해
RequestDto는 InputDto로, ResponseDto는 OutputDto로 변환하기로 했습니다.

그래서 각 DTO를 변환하는 작업이 필요했는데, 제가 구현한 방식은, 각 레이어의 DTO가 다른 레이어의 DTO에 의존하지 않도록
Mapper 클래스를 만들어 변환 작업을 관리하도록 했습니다.

이런 구조를 통해 특정 레이어의 DTO가 다른 레이어의 DTO에 의존하지 않도록 분리하려는 것이 목적이였습니다. 만약 서로 다른 레이어의 DTO가 의존하게 된다면, 작업은 편리해질 수 있지만, 레이어 간 의존성이 생겨 복잡도가 높아질 수 있다고 생각했습니다.

하지만 애기 나눠보고 싶은 점은 이런 방식이 유지보수와 확장성 측면에서 정말 최선인지 궁금합니다.
혹은 DTO 간 어느 정도의 의존성을 허용하여 개발 편의성을 높이는 방안도 고려할 수 있을 것 같은데, 다들 어떻게 생각하시나요?
Mapper 클래스를 이용한 관리 방식이 좋은지, 아니면 다른 대안이 있을지 자유롭게 의견을 나눠주시면 좋겠습니다!

[github-actions]

Test Results

 55 files   55 suites   9s ⏱️
167 tests 163 ✅ 4 💤 0 ❌
174 runs  170 ✅ 4 💤 0 ❌

Results for commit 55fac74.

♻️ This comment has been updated with latest results.