주니어 개발자입니다.
질문1
requestDto, responseDto , Dto 요런식으로 나눠서 요청시 , 응답시, 서비스랑 repository에서 돌아다닐때 로 각각 쓰고있는데 이런방식이 맞을까요?
레이어간에 dto를 나눠서 써야지 종속적이지않게 개발할 수 있다는데 모든 경우에 다 dto를 만들어서 각각 하나의 책임을 가지게 하는게 유지보수측면에서는 나을것같긴한데 제가 si1년다니면서 그런코드를 본적이 없어서요
질문2
responseDto를 지금 컨트롤러에서 만들고있는데 이거 서비스에서 만들어야된다는 의견이 많더라고요 , 서비스에서 리턴되는 도메인객체가 컨트롤러에서 responseDto로 변환되는 코드가 비즈니스로직이다 뭐다 << 요런 의견이 많던데 어떻게 생각하시나요
팀마다 다른걸로 알고 있음 1) 프로젝트가 비대하고 복잡해지면 다른 코드가 수정될 때 변경가능성을 최소한으로 줄이려고 할때 사용함. 그래서 쓸 일이 거의 없음. 서비스 기업도 MSA 때문에 쓰는 팀이 있나라는 생각도 들음. 그리고 dto 개념 만든 사람도 블로그에 1번 내용처럼 남용하지 말라고 적혀있긴함
2. 이거도 팀마다 다르다고 생각함. 여러 도메인, 다른팀 Api도 호출해서 정보를 취합해야하니 비즈니스 로직이므로 서비스에 해야한다 / 아니다 그렇게 하면 컨트롤러의 존재의의는 무엇이냐, 단순 정보 취합도 비즈니스 로직이면 걍 컨트롤러 없애고 서비스에서 요청 응답 받는게 맞는거 아니냐. 저런건 컨트롤러에 보내는게 맞다 이렇게 나뉨
뭐든지 트레이드오프라고 봅니다. 그냥 명확히 사용할 이유가 있으면 사용해도 좋다고 생각해요. 저도 주니어이긴한데 dto 너무 남용하지 말아야한다는 편이고, 2번은 후자라고 생각해요. 제 주변엔 2번은 상황에 따라 다르겠지만 굳이 서비스에?라고 생각하는 사람들이 좀 더 많은 편임
저런거 하나두개 생각하면 결국 서비스 코드 수천줄이나 되는 괴물이 탄생할 수 밖에 없는데, 이래서 회사들이 DDD를 중요시하는게 아닌가라는 생각도 들었어요. 다른 직군간 소통을 위해서 DDD를 중요시하기도 하지만, 개발 유지보수를 위해서도 DDD가 중요하다는점…??
마틴 파울러는 Service 레이어에 대해 '도메인을 캡슐화 하는 역할' 이라고 정의한 바 있음. 해당 관점에서 볼 때 레이어 간 데이터 전달 목적으로 DTO를 고수한다면 응답용 DTO를 반환하는 비즈니스 로직 역시 Service 레이어에 속해야 함. 이 경우 도메인 구조가 컨트롤러에 노출되는 리스크를 막을 수 있고, 컨트롤러는 웹 계층에 관련한 코드만 처리하게 되어 역할의 분리에 충실할 수 있음. 다만 이 경우 서비스단이 너무 무거워지고 View 레이어에 대한 종속, 컨트롤러-서비스 간 강결합을 일으킨다는 문제가 존재함.
그래서 배민은 DTO를 반환하는 로직을 서비스 레이어에서 처리하되, 컨트롤러 레이어 <-> 서비스 레이어 사이를 매핑하는 매퍼를 끼워넣어 해당 문제를 해결함. 이 경우 요청이나 응답 포맷이 변경되더라도 매퍼만 참조하는 서비스 레이어에는 아무런 영향이 올라오지 않음. 하지만 이건 배민급 서비스에서나 어울리는 엔지니어링이고, 일반적인 상황에선 Controller와 Service가 원하는 포맷이 다른 경우가 드물기 때문에 오버 엔지니어링을 경계하며 잘 조율하는 게 중요함