DTO에 Builder를 사용하는 기준은 무엇이어야 할까요?

[softmoca]

DTO는 보통 계층 간 데이터를 전달하기 위한 객체입니다.
그런데 DTO에 Builder를 붙이면 생성이 편해지는 장점이 있지만, 반대로 필수값 누락, 객체 생성 의도 흐림, 불필요한 복잡도 증가 같은 문제가 생길 수 있습니다.

그래서 고민할 질문은 이거예요.
0. DTO는 단순 데이터 전달 객체인데, Builder를 붙이는 것이 정말 좋은 설계일까? 아니면 생성자나 정적 팩토리 메서드가 더 명확할까?

1. DTO는 단순 데이터 전달 객체인데 Builder가 필요한가?
2. Builder는 생성 가독성을 높이는가, 아니면 필수값 누락 위험을 키우는가?
3. Request DTO와 Response DTO에 같은 생성 전략을 적용해도 되는가?
4. Response DTO 변환은 서비스에서 Builder로 할까, DTO의 from()으로 숨길까?
5. 테스트 편의성을 위해 프로덕션 DTO에 Builder를 추가해도 되는가?

여러분들의 의견과 접근 방법은 어떻게 되시나요?

[koreaioi]

Builder의 가장 큰 이점은 유연성이라고 생각합니다.

필드가 많더라도, 모든 값이 필수적이라면 생성자나 생성자기반의 정적 팩터리 메서드가 더 나을 수 있다고 생각합니다.
다만, 필드가 많더라도, 각 필드가 선택적으로 사용된다면 유연하게 처리할 수 있는 Builder패턴이 더 적절하다고 생각합니다.
이런 점에서 Builder 특성상 필수값 누락은 어쩔 수 없는 트레이드 오프라고 생각합니다.

• 단, 요즘은 Dto에 필드 자체를 누락하지 않는 이상, 코드 작성 시, IDE 자동완성 기능이 이를 잘 막아주는 거 같습니다

필드가 많을 때, 빌더패턴을 고려하라라는 이유도 유연성 관점에서 생각해볼 수 있을 거 같아요
Dto에 필드가 많을수록 도메인이 복잡하다는 뜻이며, 상황마다 필요한 필드 조합이 달라질 가능성이 높기때문에 Builder를 고려하라는 뜻아닐까요!

---

RequestDto와 ResponseDto는 생성 목적에 따라 생성 전략도 자연스럽게 달라졋다고 생각합니다.
RequestDto는 외부 요청으로부터의 데이터를 Spring이 요청을 받아서 Jackson을 사용해 만들어주고,
ResponseDto는 서버 내부에서 서비스 로직의 결과, 도메인 조회결과 등의 목적으로 사용되므로 생성 전략은 자연스레 다르다고 생각합니다.

---

저는 from()을 선호합니다.
서비스에서 Builder를 직접 사용하는 방식은, Dto에 들어갈 필드 내용을 알게되는 의존, 강결합이 발생한다고 생각하여 Dto 내부 from()을 만드는 걸 선호합니다.

---

테스트를 위한 코드를 프로덕션에 무작정 추가하기보다는, 다른 대안을 먼저 찾아볼 거 같습니다.
이 경우 Fixture를 만들거나, TestBuilder를 테스트 패키지에 직접 만드는 방법이 떠오르네요!