DTO 명칭·구조 혼용에 따른 컨벤션 정립 필요

[ckdals4600]

이슈 내용

DTO 생성 시 컨벤션 부재에 따른 작업자 간에 스타일 차이가 발생

문제 사항

• Request, Response 명칭 사용의 혼동
• DTO 내부에 다른 DTO를 포함시키는 방식의 혼용
• DTO 클래스 네이밍 방식이 통일되어 있지 않음

[ckdals4600]

백엔드 회의 결과에 따른 DTO 컨벤션 정리

• 이름 규칙
  • Request, Response, DTO → Req, Res, Dto로 표기
• 타입
  • 모든 DTO는 record로 작성
• 내부 구조
  • DTO 내부에서 다른 DTO 사용 시, 해당 DTO는 별도로 생성
  • DTO 내부에 Req, Res DTO 사용 금지
• 네이밍 규칙
  • 도메인 관련 DTO: 도메인 + Dto 형식
  • 그 외: API 기능 이름 기준으로 네이밍
• 기타
  • id값은 무조건 암호화하여 사용

[ckdals4600]

@Goder-0 제가 금요일부터 시골을 다녀오느라 해당 작업을 이제 진행하려고 하는데 혹시 해당 작업의 경우는 도메인별로 서브 이슈를 나누지 않고 그냥 진행해고 될까요?

[Goder-0]

@ckdals4600
혹시 이유를 알 수 있을까요?

[ckdals4600]

@Goder-0 DTO 양이 많아서 그냥 한번에 작업하는게 맞는지 궁금해 질문드렸습니다!

[ckdals4600]

@Goder-0 @minibr DTO 맴버 변수의 단변수 유무에 따른 순서 통일은 어떻게 생각하시나요 ?

예를 들어 아래와 같이 단수 데이터 타입과 복수 데이터가 존재하는 경우

public record ExampleRes (String ex1, List<Ex1Dto> ex1s, int ex2, List<Ex2Dto> ex2s)
{
}

단수 데이터들을 전부 작성한 이후 복수 데이터를 작성하는 것입니다.

public record ExampleRes (String ex1, int ex2,  List<Ex1Dto> ex1s, List<Ex2Dto> ex2s)
{
}

[ckdals4600]

@Goder-0 @minibr Gobal DTO 필요 유무에 대해서 논의하고 싶습니다!
현재 Global DTO는 특정 도메인 서비스에서 다른 도메인 서비스로 데이터를 넘겨주는 경우 사용하고 있습니다
하지만 해당 방식이 일관성 있게 유지되고 있지 않으며 서비스 간에 데이터 전달 시 굳이 DTO를 사용해야 하는 지에 대한 의문점이 생겼습니다.

[Goder-0]

@ckdals4600 해당내용은 별도의 이슈를 만들어서 논의하는게 어떠신가요? 이슈의 크기가 커질 우려가 있어 말씀드립니다

[ckdals4600]

@ckdals4600 해당내용은 별도의 이슈를 만들어서 논의하는게 어떠신가요? 이슈의 크기가 커질 우려가 있어 말씀드립니다

@Goder-0 논의의 경우 이슈보다 Discussion 탭 사용은 어떠신가요 ?

[Goder-0]

@ckdals4600 우선은 아직 이슈기반에 적응중이니 이슈로 작성함이 어떨까 합니다. 추가로, 어떤 수정을 계획하시는지등과 같은 맥락이 자세히 정리되면 좋을 것 같습니다.