DTO, VO(ex. record class), DAO(ex. JpaRepository 구현체) 개념 정리

dto(data transfer object, 데이터 전송 객체)는 클라이언트와 서버간 데이터를 전송할 때
(계층간 데이터를 전송할 때 )사용되는 객체다. dto와 vo(Value Object)의 차이는
vo는 값을 담은 객체로 불변성을 특징으로 하며, 값 자체를 표현하는데 중점을 둔다.
vo는 불변적이며, 값과 관련된 로직 포함이 가능하다. vo는 값의 동일성, 불변성을 보장하는
디자인 패턴이며, vo패턴을 간결하게 구현한 문법이 record class다.

dao(data access object)는 데이터베이스 또는 기타 영구 저장소(파일 시스템, 외부 서비스 등)에

접근하는 로직을 캡슐화하는 디자인 패턴이다(데이터베이스 접근 로직의 캡슐화).
dao의 핵심 역할은 CRUD(create, read, update, delete) 연산을 수행하여
애플리케이션의 비즈니스 로직(흐름)과 데이터베이스 접근 로직을 분리하는 것이다.
dao는 데이터베이스에 접근하고, 데이터를 변경하고(삽입, 변경, 삭제),
처리하는(ex. 조회) 역할(로직 포함)을 수행하는 디자인 패턴이다.
dao 패턴을 구현한 클래스가 JpaRepository 인터페이스 구현체다.
Spring Data JPA의 JpaRepository 인터페이스는 dao패턴을 쉽게 구현할 수 있도록
도와주는 프레임워크다.

dto는 순수하게 데이터를 전달하는 용도로 다른 로직을 갖지 않는다.
getter/setter 메서드만 갖는다. setter메서드를 갖는 dto는 데이터가 가변적일 수 있다.
setter메서드 없이 생성자를 통해 속성 값을 초기화해서 불변 객체를 만든다면
해당 dto가 계층간 전달 과정에서 데이터가 변할 수 없음을 보장할 수 있기에
안정적이다.

Entity 클래스는 데이터베이스와 매핑되어 있는 핵심 클래스이며,
이 Entity 클래스로부터 생성된 객체를 클라이언트에 전달하는 것은 권장하지 않는다.
중요한 정보를 노출할 수도 있고, Entity가 응답 객체가 되면 View에 따라
Entity 설계가 바뀌어야 하기때문에 요청에 따라 Entity객체를 dto로 랩핑(가공)해서
전달하는 것이 바람직하다.

도메인과 dto
도메인과 dto는 분리해야 유지보수성이 좋다. 핵심 비즈니스 로직이 모여있는 도메인과
데이터 전달용 객체가 분리되어 있지 않다면, 즉 하나의 객체로 클라이언트와 서버가 통신하고
(외부와의 직접적인 상호작용) 데이터베이스와도 통신이 이루어진다면,
View에(클라이언트) 반환하는 속성 값의 변경에 따라 도메인겸dto의 설계도 변경되어야 한다.
도메인과 dto가 분리되어 있다면, 다양한 요청에 따라 도메인들을 조합하여
dto에 담아 반환이 가능하기 때문에 유지보수성이 좋아진다.
유지보수를 잘 하기 위해서 화면에 의존적인 코드와(dto)
비즈니스에 의존적인 코드(도메인)를 분리하는 것이 좋다.
단, 매우 높은 확률로 dto와 도메인이 달라질 리가 없다면
도메인과 dto를 분리하지 않는 것이 좋을 수도 있다. 상황에 따라 판단할 것.

참고영상:
1. [10분 테코톡] 📍인비의 DTO vs VO: https://www.youtube.com/watch?v=z5fUkck_RZM
2. DTO와 도메인을 분리해야 하는 이유: https://www.youtube.com/watch?v=OV8e88kIU-U