DTO, VO 정리

DTO, VO 둘 다 데이터를 저장하는 객체(Object)이다.

• DTO는 데이터를 전송하기 위한 객체이며 불변일 수도 있다.
• VO는 값에 관한 객체이며 일반적으로 불변이여야 한다.

DTO : Data Transfer Object (데이터.전송.객체)

🎈 API 계층 즉 Controller 단에서 사용자와 데이터를 특정 형식으로 주고 받는 경우
🎈 Repository 단에서 select 문 안에서 DB에서 바로 DTO로 맵핑을 하여 데이터를 가져올 때.

클라이언트 사이드와 사전에 약속한 형식의 데이터를 전송하는데 있어 DTO 를 사용하면 다음과 같은 장점이 있다.

클라이언트 쪽에서 생기는 요구 사항 변경의 대하여 도메인 모델에 해당하는 Entity 와 VO 에 최소한의 수정으로 요구사항을 만족하도록 구현 할 수 가 있다.

또한 백엔드는 일관된 형식의 API Response를 사용자의 요청에 맞춰 상대방이 예측 가능한 응답을 보내야 하는 역할과 책임이 있다.

• 이 말은, 어떤 api 의 ResponseBody에 header 라는 필드가 있고, 어떤 api 의 ResponseBody에 header 라는 필드가 없다면 , 클라이언트 쪽에서는 항상 api 를 사용하기전에 확인 할 사항들이 늘어날 수 가 있다.

🎈 이러한 문제에 DTO 를 사전에 api 논의시 작성하여 모델의 설계를 늦추거나 변경에 유연하게 하면서 협업시 일정한 방식으로 응답값을 전달하는 구조를 설계할 수 있다.

DTO의 특징

• getter
• setter
• 로직을 가지지 않는다.

객체지향적인 설계 관점에서 본다면, DTO 의 "책임"은 데이터를 전달하는 것이다.
즉 , 데이터 전달의 초점을 두기 위한 약속으로 로직을 가지지 않는다라고 이해를 하면 좋을 것 같다.

VO : Value Object

VO는 비즈니스 로직에 사용되는 값으로만 비교되는 객체이다.

• 이는 다시 말하면 값에 의하여 동등성이 판단되는 객체이다.
• 결국 VO의 개념이 도메인 모델링에 밀접한 관계를 맺는 개념이라는 것을 캐치해야 한다.

VO는 일반적으로 불변성을 가지게 설계한다.

• 값을 변경할 때마다 새로운 객체를 생성하는 방식. 이는 메모리를 효율적으로 관리할 수 있다라는 것을 의미한다.
• 자주 변경하여 새로운 객체를 만든다고 하면 성능 저하가 있으니 주의하자.

아래에 참고해서 읽어보면 좋은 블로그
ref.