Entity의 속성이 Presentation layer에서 노출되는 것을 막기 위해
도메인 레이어에서 DTO 전환이 반드시 필요한 것일까
완벽하게 동일한 레이아웃인데..?
일반적으로 Entity를 DTO(Data Transfer Object)로 변환하는 것은 좋은 실천 방법임에 분명하다.
- Entity가 민감한 정보를 포함하고 있다면 보안상, DTO를 사용하여 필요 정보만 노출
- DTO를 사용하면 Presentation layer의 요구사항 변경에 더 유연하게 대응이 가능
- 필요한 데이터만 전송함으로써 네트워크 부하를 줄여 성능적으로 유리
- Entity와 Presentation layer 간의 결합도를 감소
- API 버전 관리가 용이
반면, 다음과 같은 경우에는 Entity를 직접 사용하는 것이 더 효율적일 수 있다.
- 간단한 CRUD 작업으로 복잡한 비즈니스 로직이 없는 경우
- 프로토타입 또는 소규모 프로젝트를 진행하면서 빠른 개발이 필요한 경우
- 내부용 애플리케이션이기 때문에 보안 위험성이 그렇게 높지 않은 경우
Entity가 그대로 흘러가는 경우 보안의 문제는 확실하게 있다.
업무적으로, 도메인 레이어에서 사용해야만 하는 가장 민간함 이유중에 하나이다.
- 정보 노출 방지
Entity는 데이터베이스와 직접적으로 매핑되는 객체로, 이 객체가 외부 레이어로 노출되면 민감한 정보가 무분별하게 노출될 수 있다. 도메인 레이어에서만 Entity를 사용하면, 외부 레이어(예: API, 웹 인터페이스)에서 중요한 정보가 유출되는 것을 방지할 수 있다. - 변경에 대한 통제
Entity는 종종 데이터베이스의 구조와 밀접하게 연관되어 있습니다. 이 객체를 외부 레이어에서 사용할 경우, 데이터베이스 구조의 변경이 외부 레이어에 직접적인 영향을 미칠 수 있으며, 이는 보안 문제를 초래할 수 있습니다. 도메인 레이어에서만 사용하는 것으로, 변경 사항이 보다 제어된 환경 내에서 이루어지며, 외부 레이어에 미치는 영향을 최소화할 수 있습니다. - 비즈니스 로직의 보호
도메인 레이어는 비즈니스 로직을 포함하고 있으며, 이 레이어에서만 Entity를 사용하면 비즈니스 로직이 외부의 영향으로부터 보호됩니다. 만약 외부 레이어에서 Entity를 직접 사용하면, 비즈니스 로직이 외부에서 수정되거나 악의적으로 접근될 가능성이 커집니다. - 권한 관리
도메인 레이어에서 Entity를 관리하면 권한 관리를 보다 세밀하게 할 수 있습니다. 외부 레이어에서 직접 Entity를 조작하는 것을 막아, 권한 없는 사용자가 데이터에 접근하거나 수정하는 것을 방지할 수 있습니다.
단, Entity에 민감한 속성이 없고,
Presentation layer에서 보고자하는 레이아웃이 Entity 그대로라면..?
Entity를 DTO 전환하여도 모든 속성을 그대로 가져가야 함으로 통신구간에서 성능적으로 유리할 것이 없고,
애초에 민감한 정보를 포함하고 있지 않은 Entity이기 때문에 보안상의 문제도 존재하지 않는다.
결합도를 포기하고 Entity를 반환하면 DTO 클래스와 전환코드도 필요없다.
이렇다해도, 결론적으로는 DTO로 전환하여 반환하는 방향으로 나아가려 한다.
Presentation layer의 요구사항에 유연하게 대응할 수 있고, API 버전 관리가 용이한 점을 고려할 때,
현재보다는 미래를 염두에 두어 DTO로 전환하는 것이 가장 합리적인 선택이라고 판단된다.
Controller까지 Entity를 들고와 반환하는 것은 단기적으로는 유용할 수 있으나, 시간이 비례하여 장점보다 단점으로 인한 비용적 손해가 클 것이라고 생각된다.
따라서, 전환 과정은 확장성이 있고 빠르며 명확하게 진행될 수 있어야 하고 단일 엔티티가 아닌 리스트에 포함된 대량건의 엔티티를 모두 DTO로 변환하는 과정은 반드시 최적화 되어야 한다.