DTO - Entity 변환에 대한 고민

개발하다보면 DTO - Entity를 분리해서 사용하는게 좋은 점들이 있다.

• 도메인 로직이 들어있고, DB와 매핑되는 Entity를 직접 외부에 전달하기에는 Entity에 너무 많은 역할을 쥐어준다.
• Entity에는 서버에서만 사용하는 필드가 있을 수 있다.
  • Json관련 어노테이션을 사용할 수 있지만, Entity에서 presentation과 관련된 레이어까지 관여하는것 같아서 별로..
  • Jackson converter를 별도로 구현해서 특정 엔티티에 대해 응답포맷을 변경할 수는 있을것 같다.
• Jackson말고 다른 방식의 presentation도 있을수 있으니 데이터 전달과 관련된 DTO객체를 활용하면 좋다.

이러다보니 머리속에서 걸리는 생각들

• Validation관련된 정보는 매번 중복처럼 관리해야 하나?
  • Validation관련 어노테이션들은 entity에 지정해놓으면 모든 계층에 범용적으로 사용할 수 있다는걸 장점처럼 써놨던데, DTO와 Entity가 결국 분리되면 중복으로 검증설정이 들어가야하나?
  • ㅇㅇ. DTO로 받는 값과 Entity에서 관리하는 값은 달라질 수 있기때문에 대부분 겹치긴 하겠지만, 실제로는 다른 검증로직이 필요한 경우들도 있을 수 있다. 중복으로 관리하자
• DTO와 Entity의 변환 과정은 어디서 해야하나?
  • 기본적으로는 DTO는 Controller에서만 가지고있고 service와 소통할때는 Entity로 하는것도 좋아보인다.
  • 그러나 DTO - Entity 변환과정에서 외부의 API호출이나 복잡한 로직이 필요한경우는 어떻게 하지?
  • 상황에 따라서는 Controller -> Service 는 DTO로 Service -> Controller는 Entity로 하는 것도 괜찮아보인다.

주의말것

서비스레이어에서 private convert method 사용하지 말자

DTO로 변환하는걸 다른 서비스에서도 사용하고 싶을 수 있다.

DTO에 entity -> DTO 생성자 추가는 해도 entity에서 변환로직을 추가하진 말자

엔티티에서 transport 레이어로의 의존성이 생긴다.
더 디테일한 레이어의 변경이 추상적인 레이어에 영향을 주는것은 좋지 않다.

참고

java - How to properly convert domain entities to DTOs while considering scalability & testability - Stack Overflow