2장 의미있는 이름

[ynoolee]

No description provided.

[ynoolee]

API 에 대한 응답 역할을 하는 DTO 네이밍은 어떻게 하는 것이 적절 할까요?

만약 다음과 같은 경우가 있다고 한다면

1. 게시글에 대한 단일 요청
2. 최신 게시글에 대한 다건 조회 요청

저는 최신 게시글에 대한 다건 조회 요청에 대한 응답으로 RecentPostsResponse 이런 것을 생각했습니다.
그리고는 다음 고민이 생겼었슴다.

RecentPostsResponse 안에는 List<\T> 을 담고 있고 싶은데, "T" 와 "게시글 단일 요청시 응답하는 DTO" 를 분리하고 싶다.
이렇게 하고자 하는 이유 : 다건조회 시에 포함하고 있어야 할 정보와, 단일 조회 시에 포함하고 있어야 할 정보가 다를 수도 있다(ex-다건 조회시에 보내는 Post 에 대한 컨텐츠는 컨텐츠 전체는 보여주지는 않는다던가)

그러고 나니 이 "T" 와 "게시글 단일 요청시 응답하는 DTO" 의 네이밍을 어떻게 할지가 고민이 되더라구요.
둘 다 어쨌거나 "단일" Post 에 대한 정보를 담고, 전달하는 객체 인데..

저는 이 때 결국 결론을 못 내고 그냥, PostInfo, SinglePost 이런식으로 네이밍을 했었던 거 같슴다

여러 분 이라면 어떻게 하실 것 같으신 가욥?

[HyoungUkJJang]

저도 연우님과 비슷한 고민을 종종 하게 되는 것 같습니다.
PostResponse, RecentPostsResponse 라는 네이밍이 떠오르긴 하는데 네이밍에 정말 약해서 저도 이부분은 항상 고민하고 계속 고치면서 더 나은 네이밍을 찾아가는 것 같습니다 ㅠ

---

네이밍 보다는 지금 적는 내용이 클린코드 규칙에 위반하는 부분일 것 같지만 갑자기 여러분들의 생각이 궁금해서 적어보겠습니다 !

API 응답으로 나가는 Response의 값들을 Compact 하게 만들어주는 것도 중요하지만,
게시글 단건 조회와 최근 게시글 조회 시 "필드 정보의 개수 차이가 적다면(1개 ~ 최대 5개?) 모두 그에 맞는 응답 DTO 클래스들을 하나하나 만들어주어야 하는가? "에 대한 의문이 비슷한 상황에서 항상 들었습니다.

이런 경우라면 프로젝트를 진행할 때 수 만은 도메인 클래스에 해당하는 DTO가 끊임없이 늘어나게 되면서 오히려 관리가 힘들어지고 실수 할 가능성이 생기지 않을까? (네이밍은 다르지만 필드가 똑같은 DTO 클래스) 라는 생각도 들었습니다 ㅠ

따라서 필드를 한 곳에 몰아넣고 필요한 곳에서 Optional을 이용해 안전하게 null처리를 해주면 관리가 좀 용이하지 않을까 라는 생각을 했었는데 클린코드를 이제 시작해서 모든 내용을 읽어보진 않은 상태지만 규칙을 위반하는 행위이지 않을까 라는 생각이 드네요.. ㅎㅎ

네이밍과 크게 관련이 없는 내용이였지만 이런 생각도 들어서 적어봤습니다 ! 다룬 분들의 의견도 궁금하네요 :)

고생하셨습니다 연우님 !

[YHLEE9753]

형욱님 말씀은 만들면서 배우는 클린아키텍처에도 나왔던 내용이네요! 클래스의 의도성(기능적으로 묶임)이 동반될 수 있다면 변경할 이유 또한 공유될 수 있으므로 (설계가 변경되거나 독립적으로 진화해야 한다면) 1개로 만들어서 사용하고 추후 변경해도 좋을거 같습니다. 그 과정에서 null 을 활용하는 것도 충분히 고려가능할 거 같습니다.

연우님 말씀은 스터디 하면서 깊게 이야기 하면 좋을 거 같습니다! 당장은 형욱님 의견과 동일합니다 ㅎㅎ