0. 개요

소프트웨어 설계에서 DTO(Data Transfer Object)와 Entity 간의 변환 책임을 어디에 둘지는 프로젝트 구조에 따라 달라지며, 각 방식의 장단점을 비교할 필요가 있음.

이를 위해, 실제 개발에서 자주 채택되는 네 가지 방법을 중심으로 분석

1. Entity 또는 DTO 클래스 내부에 변환 메서드를 두는 방식
2. 서비스(Service) 계층에서 처리하는 방식
3. 컨트롤러(Controller) 계층에서 처리하는 방식
4. 별도 매핑(Mapping) 유틸리티 클래스를 사용하는 방식

1. 각 계층별 처리 방식 개념 정리

1) Entity, DTO 클래스 내부에 변환 메서드 처리

✅ 개념

• Entity 또는 DTO 객체가 자기 스스로 변환 메서드(toDto(), toEntity() 또는 fromDto() 등)를 내장하고 직접 변환을 담당한다.
• 종종 정적 팩토리 메서드나 빌더 패턴과 함께 사용됨.

✅ 장점

• 코드 응집도 높음: 변환 로직이 해당 객체 내부에 존재하므로 일관성 유지에 유리함.
  • 객체가 스스로 책임을 가진다는 측면에서의 일관성
  • 수정 시 변경 범위가 좁아지는 구조적 일관성
• 빠른 구현 가능: 소규모 프로젝트에서는 별도 구조 없이 간단하게 적용 가능함.

⚠️ 단점

• SRP(단일 책임 원칙) 위반: Entity는 도메인 로직만 담당해야 하는데, DTO를 다루면서 역할이 모호해짐.
• 의존성 역전: Entity가 DTO를 참조하게 되면, 계층 구조상 하위 계층이 상위 계층을 참조하게 되어 아키텍처가 붕괴될 수 있음. → 즉 Entity가 DTO를 참조하는건 아키텍처 위반이기도 함.