[Layered Architecture] 대체 DTO는 어디에 두어야 하는가?

배경

1. 순환 참조 문제가 발생할 수 있는 기존 코드를 아래와 같은 구조로 리팩토링 하기로 했습니다.
2. Presentation Layer → Application Service Layer → Domain Service Layer → Infrastructure Layer (Controller) (Repository)

   

   https://www.thoughtworks.com/insights/blog/microservices/ddd-implemented-fp

3. Controller로 들어오는 DTO를 Application Service Layer에 다음과 같이 넘기고자 했습니다.
   

       @PostMapping
       public ResponseEntity<SuccessResponse> addActivity(@PathVariable Long semesterId, @RequestBody @Valid CreateActivityRequestDto createActivityRequestDto) {
           adminActivityApplicationService.createActivity(semesterId, createActivityRequestDto);
   
           return ResponseUtil.buildSuccessResponseEntity(SuccessCode.ADD_ACTIVITY_SUCCESS);
       }

4. 이 때, Controller로 들어온 DTO를 Service Layer에 그대로 전달해 줘도 되는가? 에 대한 의문이 생겼습니다.

DTO의 위치 및 사용 범위 

 Presentation Layer를 위와 같은 형식으로 정의했습니다.

 요청을 주고 받는 표현 계층에서 DTO를 관리하도록 했습니다. 이러면 Controller에서 Application Service와 Dto를 의존하고, 이 DTO를 그대로 Application Service에 전달하기 때문에 Application Service도 Presentation Layer에서 정의한 DTO를 의존하게 됩니다.

 이 때, 아래와 같은 문제가 발생할 수 있습니다.

1. 의존성 방향이 양방향으로 설정될 수 있습니다. 
    양방향 의존성은 순환 참조를 야기할 수 있습니다.
   Presentation Layer가 Application Service를 의존하고 있는데, Application Service가 Presentation Layer에서 정의한 DTO에 의존하게 된다면 Application Layer가 Presentation Layer에 의존하게 되므로 단방향 의존성이 깨지게 됩니다.
2. Presentation Layer(Controller)에서 전달받는 DTO가 변경되게 된다면, Application Layer까지 영향을 미칩니다.
    API가 변경되어 DTO에 전달 되는 값이 변경된다면, 이를 의존하고 있는 Application Layer의 코드도 변경해야 하는 문제가 발생하게 됩니다.

해결 방법

생각한 해결 방법은 크게 두 가지가 있습니다.

1. Presentation Layer, Application Layer 두 군데 모두 DTO를 두자.
   두 군데 모두 DTO를 두게 되면, Presentation Layer의 DTO가 변경되어도 Application Layer 에는 영향을 미치지 않게 됩니다. 하지만, 두 Layer의 DTO가 동일하다면 클래스가 불필요하게 만들어지는 효과로 이어질 수도 있습니다.
2. Presentation Layer에서 정의한 DTO를 Application Layer로 옮기자.
   Application Layer에서 DTO를 정의하고, 이를 Presentation Layer와 Application Layer에서 사용한다면 Presentation Layer -> Application Layer로 향하는 단방향 의존성을 지킬 수 있습니다. 하지만, Application Layer의 변경이 이를 의존하는 모든 Presentation Layer에 영향을 미칠 수 있습니다. 

결론

최종적으로 2번째 방법을 선택하기로 했습니다.

 프로젝트의 규모가 작기 때문에 하나의 Application Layer에 하나의 Presentation Layer만 의존하는 경우가 많았습니다. 그래서, Application Layer의 변경으로 일어나는 코드 변경이 많지 않다고 판단했습니다.

 프로젝트 규모가 큰 경우에는 다양한 Presentation Layer에서 독립적인 데이터 구조가 필요한 경우가 많을수 있으므로 1번째 방법이 더 유용하다고 생각합니다.

 

DTO의 위치와 범위에 대해서 알아보았습니다!

 항상 최적의 방법을 찾고자 노력합니다. 하지만, 각자 상황에 따라 선택이 달라질 수 있고, 정답은 없다는 것을 다시 한번 깨달았습니다.