저는 같은 데이터를 담고 있더라고 API마다 다른 DTO를 만드는 것을 선호합니다.
DTO같은 경우에는 화면에 변화에 밀접하게 관련이 있다고 생각하여 변화가 많이 있을 것으로 예상되기에 애초부터 다 따로 나누는 방식으로 개발하고 있습니다.

@hwangdaesun
화면에 밀접하게 관련된 것은 be가 fe에게 응답해주는 response dto라고 생각하고 이 응답 dto는 api마다 다르게 만드는 것이 맞다고 생각합니다.
하지만 서버 안에서 단순 정보를 전달하기 위한 dto는 API마다 나누는 것이 아닌 어떠한 정보를 전달할지 그 정보의 그룹 단위로 나눠야 한다고 생각합니다.

예를들어 dailyMealDTO , MonthMealDTO 이런 것들은 일별 조회, 월별 조회 API가 다르기 때문에 따로 분리하는 것이 아닌 하루 먹은 Meal에 대한 정보 그룹, 월에 먹은 Meal에 대한 정보 그룹으로 dto로 따로 분리해야한다고 생각합니다.

저는 같은 데이터를 담고 있더라고 API마다 다른 DTO를 만드는 것을 선호합니다.
DTO같은 경우에는 화면에 변화에 밀접하게 관련이 있다고 생각하여 변화가 많이 있을 것으로 예상되기에 애초부터 다 따로 나누는 방식으로 개발하고 있습니다.

@hwangdaesun 화면에 밀접하게 관련된 것은 be가 fe에게 응답해주는 response dto라고 생각하고 이 응답 dto는 api마다 다르게 만드는 것이 맞다고 생각합니다. 하지만 서버 안에서 단순 정보를 전달하기 위한 dto는 API마다 나누는 것이 아닌 어떠한 정보를 전달할지 그 정보의 그룹 단위로 나눠야 한다고 생각합니다.

예를들어 dailyMealDTO , MonthMealDTO 이런 것들은 일별 조회, 월별 조회 API가 다르기 때문에 따로 분리하는 것이 아닌 하루 먹은 Meal에 대한 정보 그룹, 월에 먹은 Meal에 대한 정보 그룹으로 dto로 따로 분리해야한다고 생각합니다.

@LJH098 그렇게 생각할 수도 있겠네요. 저는 DailyMealDTO와 MonthlyMealDTO가 데이터 구조는 같지만, 각각의 DTO를 받아서 해당 메서드가 수행하는 역할이 다르기 때문에, 추후 변경될 가능성을 고려하여 별도로 분리하였습니다.

PR 취소해주세요! release 브랜치로 바로 push 했네요;;