인프런 커뮤니티 질문&답변
작성한 질문수
토비선생님, 사소한 질문이 하나 있습니다.
작성
·
126
·
수정됨
0
맹목적인 파라미터의 숫자가 아닌 보통 함축적 정보를 전달하기 위해 DTO, 즉 파라미터 오브젝트를 사용해서 전달하는 방식은 워낙 간결한 방식이라 저도 선호도가 높긴 합니다.
하지만 엔티티의 영역에서 DTO와 유사한 레코드 형식의 매개변수를 전달 받는 방식은 어느 정도 엔티티의 순수성이 침해 받는 방식이 아닌가 생각이 들어서요.
실제로 작성하신 코드를 봤을 때 그런 순수성 집착 보다 휴먼 에러를 사전에 방지하는 접근 방식이라 매우 적절한 트레이드 오프라고 생각이 들기도 합니다. 이 부분에 대해서 개인적인 궁금증이 생겨서 질의 드립니다.
아직 강의를 다 본 상황이 아니라서 이런 질문을 하는 게 맞는지 작성하는 지금 이 순간 조차 고민이 되지만, 실제로 제가 생각하던 방식과의 거리감이 느껴져서 질문을 남겨봅니다.
답변 2
1
파라미터 오브젝트 리팩터링 방식은 보통 항상 같이 묶여서 다니는 정보를 취급할 때 유용하다고 알려져있습니다. 보통 의미있는 정보 그룹을 이루는 경우에 항상 같이 다니기 때문에 이를 묶어서 오브젝트로 만드는 것이 유리하죠. 이름, 성이라든가 여러가지 필드로 구성된 주소, 또는 위도, 경도 같은 것도 있을 거고요. 반면 DTO는 데이터 이동의 횟수를 줄이기 위해서 씁니다. getter를 여러번 호출하게 하는 대신 하나의 오브젝트로 묶어서 리턴하는 경우도 있고, 반대로 여러개의 파라미터로 쪼개진 것들을 묶어서 전송하기 위해서 사용하기도 합니다. DTO는 워낙 넓은 범위에서 여러가지 이유로 사용되기 때문에 딱 이런 경우에 쓴다고 설명하기는 어렵긴 합니다.
이번 강의 예제에서는 회원을 생성하는데 필요한 여러 정보를 묶어서 파라미터 오브젝트 같기도 하고 DTO 같기도 한 형식으로 전달하는 방식을 선택했습니다. 당연히 여러가지 방법이 있다는 것을 설명했고, 그 중에서 단일 오브젝트로 전달하는 것을 사용해보기로 했습니다. 그런데 계속 개발하다 보면 이보다 다른 방식이 더 낫다고 판단할 수도 있습니다. 그럼 그때 바꾸면 됩니다. 이게 클린 스프링에서 지향하는 방식입니다. 일단 지금 시점에 여러가지 조건을 가지고 트레이드 오프를 해서 일단 결정을 한 것이고요. 아직까지는 나쁘지 않다고 봅니다.
이게 웹 계층으로부터 전달될 것인지 서비스 계층의 파라미터로 쓰일지 말지는 도메인의 관심사가 아닙니다. 그건 결과적으로 그렇게 활용됐지만 나중에 바뀔 수도 있습니다.
반면에 도메인 모델인 엔티티 설계 관점에서는 이 결정이, 그러니까 회원을 생성하는 정보는 이런 저런 것이 있고, 이것이 생성을 위해서 반드시 필요하다는 도메인의 지식, 이야기를 코드로 표현해 보니 이게 자연스럽게 보였을 뿐입니다. 물론 긴 파라미터 리스트가 예상이 됐던 것도 있지만, 그건 부차적인 것이고 우선적으로는 도메인에 충실하게 표현하려고 했을 뿐입니다.
이름, 이메일, 비밀번호를 가지고 회원을 생성한다는 것이 회원 엔티티에 대한 도메인 지식입니다. 게다가 이 세가지는 필수라고 했고, 여러가지 제약조건들도 있습니다. 이것도 도메인 지식이죠. 개발자든 도메인 전문가든 함께 논의하고 이걸로 커뮤니케이션을 했습니다. 그리고 이렇게 구상한 모델을 코드에 그대로 반영할 때, 회원 등록을 위해서 필요한 정보가 어떤 것이 있다, 그리고 어떤 조건을 가지고 있다라는 도메인 모델을 긴 파라미터 리스트로 표현하는 것보다 회원 정보를 생성하기 위해서 엔티티의 생성 기능을 가진 행위에게 전달하는 오브젝트를 만들어서 선명하게 드러내는 것이 낫다고 판단했습니다. 그 안에 이 정보에 대한 각종 검증 로직이 들어갈 수도 있겠죠.
도메인에는 DTO를 쓰면 된다 안된다, 이건 중요한 얘기가 아닙니다. 누가 그런 걸 정했나요. 저는 그보다는 도메인에 대해 이야기하고 생각하고 정리한 것, 모든 참여자들이 가지고 있는 회원의 최초 등록에 대한 멘탈 모델과 코드를 최대한 가깝게 표현해보려고 했을 뿐입니다. 저는 아직은 엔티티의 순수성을 전혀 침해했다고 생각하지 않습니다. 회원 생성 정보를 담은 레코드 클래스는 도메인 계층에 존재하는 도메인 구성 요소입니다. 이걸 밖에서 만들어서 전달하는 DTO라고 먼저 생각하면 순수성이 해쳐진 건가라고 생각하실 수 있겠는데, 그렇지 않자나요. 웹이나 서비스에서는 어떻게 정보가 다뤄지든 도메인으로 넘어올 때는 그렇게 정보를 표현해서 기능을 이용하도록 의도된 것입닉다.
물론 여러가지 이유로 나중에 그보다 나은 표현 방법이 있다면 그때 변경하면 됩니다. 제가 답변 드릴 수 있는 건 이 정도네요. 이해하시는 데 도움이 되셨나요.
0
안녕하세요, 인프런 AI 인턴입니다. 임동현님께서 질문해주신 내용을 읽고 유사한 고민을 가진 학습자들이 있었음을 알게 되었습니다. 질문하신 내용은 엔티티 내에서 DTO와 유사한 객체를 사용하는 방식에 대한 고민이시군요.
엔티티와 DTO 사용에 대한 고려사항
엔티티는 보통 데이터베이스 테이블과 직접적으로 매핑되는 클래스입니다. 반면 DTO(Data Transfer Object)는 계층 간의 데이터 전송을 용이하게 하기 위한 객체로, 주로 비즈니스 로직에 의존하지 않는 구조를 가져야 합니다.
채택하는 설계 방식에 따라 엔티티와 DTO를 중첩하거나 분리하는 방법이 서로 다를 수 있습니다. 다만 다음과 같은 장단점을 고려할 수 있습니다:
장점:
- 매개변수 목록이 복잡할 경우, DTO를 사용하여 파라미터를 구조화하면 코드의 가독성이 높아집니다.
- 특정 데이터를 캡슐화하여 명확한 데이터를 처리할 수 있습니다.
- 매개변수 목록이 복잡할 경우, DTO를 사용하여 파라미터를 구조화하면 코드의 가독성이 높아집니다.
단점:
- 엔티티의 상태를 DTO로 직접 변경하면, 엔티티의 순수성과 도메인 로직의 혼합이 우려될 수 있습니다.
- DTO와 엔티티 간의 매핑에서 실수가 발생할 수 있습니다.
- 엔티티의 상태를 DTO로 직접 변경하면, 엔티티의 순수성과 도메인 로직의 혼합이 우려될 수 있습니다.
유사한 논의가 된 예
유사한 주제에 대한 자세한 논의는 토비님의 답변을 통해 보강할 수 있습니다:
위 링크에서 강사님이 다양한 접근 방법과 관련된 설계 철학을 설명하고 계시니 참고해 보시면 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다.
먼저 답변 주신 내용에
도메인에는 DTO를 쓰면 된다 안된다, 이건 중요한 얘기가 아닙니다. 누가 그런 걸 정했나요.이 부분에 오해가 있으신 거 같아 정정을 해야 할 것 같습니다. 정적 팩토리 메서드에서 매개변수로 레코드를 받는 상황이 특정 사용 계층과 엔티티 클래스에서 타 클래스(레코드) 를 알아야 한다는 상황에 대한 관점에서 나온 질의였습니다. 관계 설정에 대한 미묘한 차이를 아직 직관적으로 해석하지 못해 의문을 갖게 되었습니다.도메인의 구성 요소로 바라보는 관점이라면, 실제로 DTO같은 개념보단 도메인에 대한 필수 정보를 압축한 클래스(VO 같은)로 바라 볼 수 있다고 생각이 드네요. 해당 강의 중, 어떠한 기술적 연결이 없는 상황에서 도메인 해석 및 작성 하신 것에 대해 제가 비약적 해석을 해서 접근을 한 것 같습니다.
주신 답변에서 의도를 나름 정확하게 이해 했는지 불확실 하지만, 주신 답변을 여러번 읽고 다시 한번 생각해보겠습니다. 감사합니다