DTO를 api 스펙에 fit하게 생성하자는 의견

[lcqff]

저희 두레 백엔드 팀은 가능한 DTO를 재활용해 사용할 수 있도록 결정한 바 있습니다.
이유는 아래와 같습니다.

• 유지보수를 생각하기에 두레는 그렇게 규모가 크지 않음
• 미리 유지 보수를 생각하여 모든 DTO를 생성하는 것은 비효율적

따라서 DTO 생성시 API 스펙에 fit하게 생성하지 않고, 조회하는 엔티티가 포함하고 있는 모든 정보를 담아 전달하는 식으로 DTO를 제작했습니다.
(ex. study 조회시 team, crop, curriculum의 정보도 함께 조회한다.)

그러나 위와 같은 방식으로 DTO를 사용해본 결과 해당 방식이 주는 이점이 잘 와닿지 않습니다.

• 유지보수를 생각하기에 두레는 그렇게 규모가 크지 않음
  • dto 측면에서 고려해야할 것은 두레의 규모보다는 각 엔티티들이 다른 엔티티와 얼마나 긴밀하게 연관돼있는가라고 생각합니다. 현재 두레 엔티티 중 fan out,fan in이 2개 이상 발생하지 않는 엔티티는 crop을 제외하면 존재하지 않습니다.
• 미리 유지보수를 생각하여 모든 DTO를 생성하는 것은 비효율적
  • 오히려 존재하지도 않는 다른 api를 위해 중복사용이 가능하도록 DTO를 생성하는 부분이 더 비효율적으로 느껴졌습니다. 현재 '나의 스터디 목록 조회'가 가져오는 정보는 아래와 같습니다.

        final ResponseFieldsSnippet responseFieldsSnippet = responseFields(
                numberFieldWithPath("[].id", "스터디의 ID"),
                stringFieldWithPath("[].name", "스터디의 이름"),
                stringFieldWithPath("[].description", "스터디의 설명"),
                stringFieldWithPath("[].startDate", "스터디의 시작일"),
                stringFieldWithPath("[].endDate", "스터디의 종료일"),
                stringFieldWithPath("[].status", "스터디의 진행 상태"),
                booleanFieldWithPath("[].isDeleted", "스터디의 삭제 여부"),
                numberFieldWithPath("[].teamReference.id", "스터디가 속한 팀의 ID"),
                stringFieldWithPath("[].teamReference.name", "스터디가 속한 팀의 이름"),
                stringFieldWithPath("[].teamReference.description", "스터디가 속한 팀의 설명"),
                stringFieldWithPath("[].teamReference.imageUrl", "스터디가 속한 팀의 이미지 url"),
                numberFieldWithPath("[].cropReference.id", "스터디의 작물의 ID"),
                stringFieldWithPath("[].cropReference.name", "스터디의 작물의 이름"),
                stringFieldWithPath("[].cropReference.imageUrl", "스터디의 작물의 이미지 url"),
                numberFieldWithPath("[].curriculumItems[].id", "스터디의 커리큘럼 ID"),
                stringFieldWithPath("[].curriculumItems[].name", "스터디의 커리큘럼 이름"),
                numberFieldWithPath("[].curriculumItems[].itemOrder", "스터디의 커리큘럼 순서번호"),
                booleanFieldWithPath("[].curriculumItems[].isDeleted", "스터디의 커리큘럼 삭제여부")
        );

그 외 사유는 아래와 같습니다.

• DTO를 중복사용하는 경우 DTO에 수정사항이 발생했을 시 해당 DTO와 관련된 모든 코드를 수정해야한다.
• 또한 restDocs 작성이 번거로워집니다. 복사 붙여넣기를 사용한다고 해도, 의도대로 DTO를 재사용해 다른 DTO에 포함시킬 경우: 예를 들어 나의 스터디 정보와 다른 엔티티 정보를 함께 들고오는 DTO를 새로 생성한 경우 restdocs 코드를 작성하기 위해 (위에 보이는) 나의 스터디 목록 조회의 모든 responseFields 앞에 []를 추가해주어야 합니다.

[JJimini]

DTO에 대해 많이 생각해보셨군요! 수고하셨습니다.
우선 저의 생각을 말씀드리면 저는 처음 DTO 방향성을 결정할 때부터 DTO는 api에 fit하게 생성하자라는 의견이었습니다.😊
그럼에도 불구하고 당시 "API를 재사용하자"라는 의견에 동의한 이유는 기재되어있던 이유와 같았습니다. 하지만 서로 이해한 부분이 다른 것 같습니다.

제가 API를 재사용에 동의한 부분은 다음과 같습니다. 예를 들어,

1. Study의 DTO를 api에 fit하게 만들었음
2. Curriculum에도 똑같은 형태의 DTO가 필요함
3. 이럴 때 Curriculum에 (이름은 다르고 ) Study의 DTO와 내용은 동일한 DTO를 또 생성하는 것이 아닌, 범용적인 이름을 명명하고 같이 쓰자!

이런 의미었습니다!

팜님께서 말씀하신 DTO를 최소화시키기 위해 모든 정보를 다 넣자라는 의미가 아니었습니다...! 이런 부분은 코드 리뷰에서 의견을 나누어 조정했어야 했으나 이야기가 잘 이루어지지 않아 이렇게 작성된 것 같습니다.. 결론적으로 저는 DTO에 필요한 정보만 넣어야 한다는 의견에 동의하며, 필요한 정보가 같을 경우 DTO를 재사용하는 것이 좋다!라는 의견입니다!😃😃

[lcqff]

확실히 백엔드 인원마다 이해한바가 다른 것 같습니다😂😂 저도 범용적으로 쓰일법한 (간략화된 조회같은?) 부분은 하나의 dto를 돌려써도 괜찮을것 같습니다. 오히려 그럴 이유가 없어보이구요
어디를 어디까지 돌려쓸까?에 대한 기준을 정할순 없을 것 같고 서로 리뷰로 맞춰가면 좋을 것 같습니다! (물론 미나님께서 알잘딱하게 잘해주실것 같지만요)