엔티티 생성시 DTO 의존 여부에 대한 고민

서비스 단에서 엔티티를 생성할 때 DTO를 넘겨줘야할 지 DTO를 분리하여 엔티티에 속성값에 해당하는 값들을 넘겨줘야할 지 고민이 되었다.

내가 참고한 레포들은 DTO를 넘겨주고 있었는데, 이렇게 한다면 도메인에서 DTO에 대한 의존성이 생기기 때문에 별로 좋지 않다고 생각했다. 또한 팀원 역시 DTO를 분리하여 넘긴다면 코드가 너무 더러워 보일것 같기도 하고 캡슐화적인 측면에서 엔티티 내부의 내용을 숨길수 있기 때문에 DTO를 넘기는 것이 좋을것 같다고 했다.

하지만 나는 다른 의견이였는데, 오히려 분리하는것이 코드를 읽을때 이해하기 수월할 것 같다고 생각했다. 엔티티에 어떤 내용이 들어가는지 한 눈에 알 수 있기 때문이다.

캡슐화적인 측면에서는 내가 제대로 알지 못하여 조금 찾아보았고 다음과 같은 결과를 알게 되었다.

우선 캡슐화가 의미 하는 것은 서로 연관있는 속성과 기능들을 하나의 캡슐로 만들어 데이터를 외부로부터 보호하는 것을 말한다. 이런 캡슐화를 하는 의미는 크게 두가지가 있는데

데이터 보호, 데이터 은닉 이다.

데이터 보호는 외부로부터 클래스에 정의된 속성과 기능들을 보호하고

데이터 은닉은 내부의 동작을 감추고 외부에는 필요한 부분만 노출하는것

을 의미한다. 이렇게 하여 각 객체 고유의 독립성과 책임 영역을 안전하게 지키고자 하는 목적이 있다.

이런 의미를 찾았고 우리의 상황에 대입을 해봤다. 캡슐화가 데이터를 보호하고 은닉하는 것이 객체 고유의 독립성과 책임 영역을 안전하게 지키고자 하는 것 이면, 오히려 DTO에 대한 의존성이 생기는 것이 독립성을 해치는 것이 아닌가? 에 대한 생각을 떠올렸다. 또한 데이터들을 보호하고 은닉하는 캡슐화가 존재하는 이유 역시 결국엔 각 객체의 동작을 숨겨서 내부 동작이 바뀌더라고 다른 코드에 영향이 가지 않도록 하기 위함이라고 판단했고, 엔티티 생성 인자 자리에 DTO가 들어가던 각 속성들이 들어가던 큰 상관이 없다고 생각했다. 어차피 DTO안에 그 정보들이 다 들어가 있는데 데이터 보호의 의미가 크게 있을까 라는 생각을 했다. 추가적으로 DTO를 분리시 엔티티 생성에 들어가는 속성들의 자리가 달라지면 동작에 큰 오류가 발생하고 헷갈린다. 라는 의견이 존재했다. 이 의견에 동의하는 부분이 크긴 하지만, 전달해주는 DTO역시 생성시 여러가지 인자들이 발생할 가능성이 있기 때문에 나는 분리하여 전달하는 것을 선택했다.

후에 좋은 기회로 네트워킹 데이에서 파워 블로거 망나니 개발자님을 뵐 기회가 생겼는데 다음과 같이 답해주셨다.

" 데이터 베이스에 저장하는 영속성 엔티티와 비즈니스 정책을 담당하는 엔티티를 관리해야 하지만 보통 결합해서 많이 사용한다. 엔티티가 DTO를 아는 것은 바람직하지 않지만 DTO가 엔티티를 아는 것은 괜찮다. 왜냐하면 엔티티는 비즈니스 정책을 담아야 하는 중요한 계층이고 애초에 DTO 라는 것이 데이터 트랜스퍼 오브젝트 라는 약자이고 데이터를 계층 간에 전달을 해야 한다라는 명확한 목표가 존재한다. 그렇기에 dto에서 엔티티를 변환하는 로직을 넘겨주는 게 가장 깔끔한 구조이다"

내가 이해한 바로는 DTO는 엔티티에 대한 의존성을 갖고 있어도 괜찮지만, 엔티티, 즉 도메인 영역에서 DTO를 아는 것은 바람직 하지 않다. 그 이유로는 도메인은 가장 핵심적인 영역인데 여기에서 DTO는 핵심 비즈니스 영역이 아니기 때문에 도메인이 DTO를 아는 것은 옳지 않다. 라고 이해를 했다.

시간이 너무 없어서 추가 질문을 하지 못했는데 명함을 받았어서 그 후 연락을 취했고 따로 커피챗을 요청드렸는데 흔쾌히 수락해 주셨다. 커피챗에 가서 보다 더 자세하기 들을 예정이다.