RequestDto 의존방향, 사용범위 어떻게 사용하시나요?

Question

RequestDTO 의 경우 표현계층에서 생성이되고 이걸 응용 서비스 계층에서 그대로 받아 사용하게 되면 결국 하위 계층에서 상위 계층을 의존하게 된다고 생각하는데 결국 DDD에서 말하는 하위 모듈이 상위 모듈을 의존해서는 안된다에 해당하는건지 궁금합니다. 단순히 생각해봤을 때 RequestDTO를 그대로 넘겨 받아사용하는게 훨씬 개발할 때 편리할 것 같은데.. 이렇게 사용해도 되는지 아니면 하위 계층에서 사용하는 DTO 로 변환해서 넘겨야하는지, 그것도 아니라면 그냥 매개변수로 다 꺼내서 전달해줘야하는지 확신이 서질 않네요.다른 분들은 어떻게 생각하시는지 궁금합니다.

장독깨기 · Accepted Answer

특정 내용을 읽어 SMS 또는 카톡으로 알람을 보내는 모듈이 있다 해보겠습니다.그럼, 이 모듈은 전송 클래스를 파라메터로 뭘 받아야 할까요.SMS 을 보내는 클래스 또는 카톡으로 보내는 클래스를 파라메터로 받으면 안 되겠죠.이렇게 하면 알람을 보내는 모듈을 각각 별개로 만들어야 할 겁니다.이때, 전송 인터페이스를 만들고, 이 인터페이스에 전송 메서드를 만듭니다.인터페이스로 추상화를 한거죠.그리고, SMS 와 카톡 은 저 인터페이스를 구현하고, 알람을 보내는 모듈은 이 인터페이스를 파라메터로 받으면 모듈 하나로 처리가 됩니다.여기서 인터페이스와 이걸 구현한 구현체는 상하위 관계가 생기는 거죠. 이 인터페이스에 의존 관계를 가져라는 얘기입니다. 그니까, SMS 나 카톡 클래스로 의존 관계를 맺지 마라는거죠.그런데, DTO, VO, Entity 이런 것들은 데이터 객체입니다. 추상화 할 대상도 아니고 추상화 할 수도 없는 단순 데이터를 담은 객체일 뿐 입니다.그니까, 그냥 편한데로 끌리는데로 하면 됩니다. 정답이 없고, 일관성만 좀 지키면 될 일 입니다.저는 그냥 일관성 있게 전부 Map 사용합니다. :)

개잡부대장 · Answer

저의 경험상 다 케바케그냥 DTO(VO) 딸랑 하나 가지고 사용하는 곳도 있고최초 request시 requestDTO 로 받은다음 서비스계층에서 사용할 DTO 혹은 entity로 변환한다음 사용하거나아니면 그냥 requestDTO 그대로 넘겨받아서 쭉 사용하거나위 3가지 방식 저는 다 사용합니다. 개발 컨벤션 맞춰주는거 좋아해서

RequestDto 의존방향, 사용범위 어떻게 사용하시나요?

2개의 답변

기술 목록