강의

멘토링

로드맵

Inflearn Community Q&A

gyrbs22's profile image
gyrbs22

asked

Learning Large-Scale System Design by Building Directly with Spring Boot - Bulletin Board

Implementing Infinite Depth Comments - CUD API & Inserting Test Data

27강(댓글 무한 depth - CUD API 구현 & 테스트 데이터 삽입 Comment Response 관련 질문)

Resolved

Written on

·

47

0

  • 학습 관련 질문을 최대한 상세히 남겨주세요!

  • 고민 과정도 같이 나열해주셔도 좋습니다.

  • 먼저 유사한 질문이 있었는지 검색해보세요.

  • 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.

안녕하세요 선생님!

 

강의 정말 잘 수강하고 있습니다. 선생님 덕분에 기본기가 탄탄해지는 것 같아서 감사드립니다.

 

27강(댓글 무한 depth - CUD API 구현 & 테스트 데이터 삽입 Comment Response 관련 질문) - 24분 가량에서 Comment V2 생성을 위한 정적 팩토리 메소드의 경우 CommentResponse 책임으로 넣으셨는데, 굳이 책임을 CommentResponseV2로 넣을 정도로 큰 부분이 아니기에 하나로 넣으신건지, 아니면 프로젝트 규모적으로 보았을때 굳이 V2 Response를 생성할 정도의 규모가 아니기에 따로 만드시지 않고 하나의 Response 객체로 사용하신 것인지 궁금합니다.

나중에 프로젝트 아키텍칭을 할 때 해당 내용을 기억하기위해 질문드리고자 합니다.

감사합니다.

javamysqlspring-bootkafkaredis

Answer 2

0

kuke님의 프로필 이미지
kuke
Instructor

Hyo Kyun Lee님, 안녕하세요!

강의 잘 수강해 주시고 계셔서 감사합니다!

(요즘 평일에 시간이 없어서 답변이 늦어 양해 바랍니다..!)

 

엄밀히 따지면, V1과 V2에서 사용될 수 있는 필드가 다르므로 V2로 분리하는게 맞습니다.

다만, 클라이언트에게 하위 호환성이 지켜질 수 있고, 딱히 복잡하지 않고 간단한 내용이라면, 대부분의 필드가 동일하기 때문에 굳이 복제 안하고 그대로 사용하기도 하네요.

꼭 정답이 있다기 보단, 상황 또는 팀의 컨벤션을 따라가게 되는 것 같습니다.

대신 분리하지 않고 사용한다면, 클라이언트에게 노출되는 응답 데이터이므로 어떠한 버전에서 사용되는 필드인지 명확하게 문서화는 필요합니다!

Hyo Kyun Lee님의 프로필 이미지
Hyo Kyun Lee
Questioner

감사합니다 선생님!

선생님께서 구성하신 Response, Request를 보면 말씀해주신 사유로 철저하게 분리하셨기에, 해당 Comment Response는 왜 분리하지 않고 하나로 통합하여 사용하는지 궁금하였습니다.

하나의 사소한 차이가 그만큼 경쟁력있는 설계와 품질로 이어질 수 있다는 생각에 궁금해져서 질문드리게 되었습니다.

말씀하시는 내용들 하나하나 최대한 깊고 넓게 살펴보면서 어제의 저보다 100배 성장하고 있음을 몸소 느끼고 있습니다.

감사드립니다!

끝까지 완강하겠습니다.

0

안녕하세요, 인프런 AI 인턴입니다.
Hyo Kyun Lee님께서 질문해 주신 내용에 대해 답변 드리겠습니다.

스프링 부트 프로젝트에서 API의 확장성과 관리 용이성을 위해 다양한 버전의 Response 객체를 사용하는 것은 프로젝트의 규모와 복잡성에 따라 결정됩니다. CommentResponseV2와 같은 정적 팩토리 메소드의 사용은 데이터 구조 변화의 가능성을 대비하고자 하는 계획의 일환일 수도 있습니다.

하지만 강의에서 굳이 CommentResponseV2를 따로 두지 않고 하나의 Response 객체로 사용한 경우라면, 현재 프로젝트나 그 부분의 규모에서는 별도의 버전 관리가 필요 없다고 판단했을 가능성이 큽니다. 즉, 프로젝트의 복잡성과 응집도를 고려했을 때, V1과 V2 사이의 큰 차이가 없고 유지보수에 불편함이 없을 것이라 판단되면 하나의 클래스에서 처리하기도 합니다.

나중에 프로젝트를 확장하거나 구조를 변경할 필요가 있을 때, 이런 결정을 통해 코드의 간결함과 관리성을 유지하는 방법을 배우실 수 있습니다. 필요에 따라 나중에 변경하는 것도 충분히 가능하니 현재는 복잡성을 억제하면서 기본기에 충실한 소스를 유지하는 것도 좋은 접근입니다.

추가적인 도움이 필요하다면 Stack Overflow나 Spring Boot 공식 문서를 참고하시기 바랍니다. 계속해서 학습을 이어가시길 바랍니다! 감사합니다.

Spring Boot 공식 문서 링크

gyrbs22's profile image
gyrbs22

asked

Ask a question