DTO는 어떤 Layer에 포함되어야 하는가.

최근에 Dto Mapper에 관련된 글을 쓰며, 생각보다 많은 프로젝트에서 아래와 같은 코드를 많이 사용한다는 걸 알았다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/")
public class ItemApiController {
    private final ItemFacade itemFacade; // package.application.ItemFacade
    private final ItemDtoMapper mapper;


    @GetMapping("/register")
    public CommonResponse register(@RequestBody @Valid ItemDto.RegisterItemRequest request) {
        var itemCommand = mapper.toCommand(request); // package.domain.ItemCommand
        var itemInfo = itemFacade.register(itemCommand); // // package.domain.ItemInfo 
        var response = mapper.toResponse(itemInfo); 
        return CommonResponse.success(response); // package.presentation.ItemResponse
    }
}

실제 스프링 가이드로 유명한 baeldung.com 의 예제코드도 이러하다.

@RestController
class PostRestController {
    @Autowired
    private ModelMapper modelMapper;

    @GetMapping
    public List<PostDto> getPosts(...) {
        //...
        List<Post> posts = postService.getPostsList(page, size, sortDir, sort);
        return posts.stream()
          .map(this::convertToDto)
          .collect(Collectors.toList());
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public PostDto createPost(@RequestBody PostDto postDto) {
        Post post = convertToEntity(postDto);
        Post postCreated = postService.createPost(post));
        return convertToDto(postCreated);
    }

    @GetMapping(value = "/{id}")
    public PostDto getPost(@PathVariable("id") Long id) {
        return convertToDto(postService.getPostById(id));
    }

    @PutMapping(value = "/{id}")
    @ResponseStatus(HttpStatus.OK)
    public void updatePost(@PathVariable("id") Long id, @RequestBody PostDto postDto) {
        if(!Objects.equals(id, postDto.getId())){
            throw new IllegalArgumentException("IDs don't match");
        }
        Post post = convertToEntity(postDto);
        postService.updatePost(post);
    }
}

 

DtoMapper와 함께 위와 같은 코드를 사용하면 많은 장점이 있다.

• Application(Service) 레이어는 Request, Response에 대해 몰라도 된다.
• Presentation(Controller) 레이어만 입출력을 관리하기 때문에, 유연성이 뛰어나고 코드가 깔끔해진다.

 

 

 

💭 하지만 우리 프로젝트에선 사용할 수 없어요

현재 프로젝트에서는 아래와 같은 패키지 구조를 가지고 있다.

도메인을 사용하려면 반드시 어플리케이션 레이어를 거쳐야한다. 진입점을 하나로 만들고, 의존성 관리하기 위함이다. 

여기서 문제가 발생한다. 컨트롤러에서는 Domain Dto (ItemInfo, ItemDto 등)을 사용하거나 import 할 수 없다.

• Dto는 도메인 레이어에 존재하기 때문에, 컨트롤러에서 꺼내서 사용할 수 없다.

@GetMapping("/register")
public CommonResponse register(@RequestBody @Valid ItemDto.RegisterItemRequest request) {
    var itemCommand = mapper.toCommand(request); // package.domain.ItemCommand
    var itemInfo = itemFacade.register(itemCommand); // // package.domain.ItemInfo 
    var response = mapper.toResponse(itemInfo); 
    return CommonResponse.success(response); // package.presentation.ItemResponse
}

 

🙄 : 그럼 [도메인 안에 DTO]를 사용하지 않으면 되잖아요? 다른 계층에만 따로 만들죠?

맞는 말이다. '도메인 DTO'를 아예 사용하지 않고, 아래처럼 도메인 서비스에 하나하나 필드를 까서 넣으면 된다.

// Application 레이어 - AccountFacade 코드
@Transactional
public RegisterAccountResponse register(RegisterAccountCommand request) {
    var entity = accountService.register( // 또는 registerAccountProcessor.register(..)
        request.getUserId(),
        request.getEmail(),
        request.getPassword());

    return new RegisterAccountResponse(entity.getUserId(), entity.getEmail());
}

 

실제로 반 버논 - 도메인 주도 설계 핵심 (IDDD) 샘플코드를 보면, 위와 같은 방법으로 필드를 하나하나 넣고있다.

 

하지만 이 방법으론 한계가 있다. 아래와 같이 필드가 엄청 많다면? 과장한게 아니라, 실제로 저런 DTO가 많이 사용된다.

@Getter
@Setter
@ToString
public static class RegisterOrderRequest {

    private String orderToken;
    private Long userId;
    private String payMethod;
    private Long totalAmount;
    private String orderedAt;
    private String status;
    private String statusDescription;
    private String receiverName;
    private String receiverPhone;
    private String receiverZipcode;
    private String receiverAddress1;
    private String receiverAddress2;
    private String etcMessage;

    private List<RegisterOrderItem> orderItemList;
}

 

이런 경우, 도메인 메서드의 파라메타는 10개, 20개가 될 것이다. 

이 코드는 흔히 말하는 클린코드와는 거리가 매우 멀다. 도메인 Dto(OrderInfo, OrderDto)에 포장해서 전달해야한다.

public register(Long userId, Long totalAmount, String orderToken,
    String payMethod, String orderedAt, String status, ...)// 이렇게 20개의 파라메타를 받을건가?

 

 

💭 Request, Response는 어느 레이어에 둬야 하는가.

🙄 : ?? 당연히 컨트롤러가 있는 프레젠테이션 레이어겠죠!

 

나도 처음엔 그렇게 생각했다. 하지만 컨트롤러와 어플리케이션의 코드를 보자.

@PostMapping("/signup")
public ApiResponse<RegisterAccountResponse> register(
    @Valid @RequestBody RegisterAccountCommand request) {
    return ApiResponse.success(accountFacade.register(request));
}

// Application 레이어 - AccountFacade 코드
@Transactional
public RegisterAccountResponse register(RegisterAccountCommand request) {
    var entity = accountService.register( // 또는 registerAccountProcessor.register(..)
        request.getUserId(),
        request.getEmail(),
        request.getPassword());

    return new RegisterAccountResponse(entity.getUserId(), entity.getEmail());
}

 

Request가 프레젠테이션에 존재하는 경우, App 레이어가 Presentation 레이어를 의존하게 된다.

Application은 Presentation을 알 필요가 전혀없다. 도메인 작업을 위임하고, 외부 앱을 호출하는 역할만 가진다.

 

좀 더 쉽게 비유해보자면 Application은 TV 리모컨과 같은 역할이다. 

리모컨을 만드는데 어떤 사람이 사용할지를 정확하게 알아야할까? 아니다. 소비자(Presentation)가 리모컨을 사용하는 거지, 리모컨이 소비자를 알 필요는 전혀 없다.

 

그럼 가장 깔끔한 방법은 각 계층마다 DTO로 도배해놓는 것이다.

DomainDto ➡ AppDto ➡ ControllerResponse 이렇게 3개의 Dto를 사용하면, 의존성이 꼬이지 않고 처리할 수 있다.

우리는 클린코드, 클린아키텍처등을 공부하면서 변화의 방향, 의존성을 통제하는 것의 중요함을 알고있다.

• application은 도메인을 캡슐화하고, 앱 진입점을 하나로 만들어준다.
• SRP 원칙. 컨트롤러가 변경된다 해서 도메인에 영향이 있으면 안된다. 이는 반대도 마찬가지
• application에 컨트롤러 Request의 의존성이 생기면 안된다. 이는 Http Request라는 하위 기술에 앱이 묶이게된다.

이 그림처럼 하면 '이론으로는 가장 깔끔한 코드'가 나온다.

하지만 도메인 모델과 똑같은 DTO를 3개씩 만들어서 변환하다보면, 이 노가다를 계속하는게 맞나 의심이 든다.

 

🙄 : 의존성을..이렇게 까지 관리할 필요는 없지않을까? DTO정도는 그냥 쓰자

살짝 뻘짓이긴하지만.. DTO를 컨트롤러에서 숨기려고 아래와 같은 코드를 사용할까 고민한 적도 있다.

mapper.toResponse( MemberFacade.create ( mapper.toCommand( request ) ) );

@GetMapping("/register")
public CommonResponse register(@RequestBody @Valid CreateMemberRequest request) {
//        var itemCommand = mapper.toCommand(request);
//        var itemInfo = itemFacade.register(itemCommand); 
//        var response = mapper.toResponse(itemInfo);
 
    // 한줄로 작성해서 DTO 숨겨버리기 (mapper만 Presentation에 의존성이 있으며, 이는 Application에 둔다.)
    var response = mapper.toResponse(MemberFacade.create(mapper.toCommand(request)));
    return CommonResponse.success(response); 
}

 

 

 

💭 아니 그래서 결론이 뭐에요

정해진 답이 없다는게 결론이다. DTO를 어떻게 사용하는가는 정답이 없다.

모든 곳에 완벽한 은탄환은 없다.

상위레이어(Controller)에서 하위레이어(App, Entity)를 참조하는 건 당장 큰 문제가 되지는 않는다.
사용하는 목적에 맞게 적절히 타협해서 쓰면 된다. 정답은 없다.

• 'DTO를 어떻게 쓰냐'로 가면 영원히 해결되지 않는다.
• '왜 DTO를 사용하는가?' 에 초점을 맞춰서 나에게 맞는 방법을 찾아야한다.

Domain에 다른 계층의 의존성이 있을 필요도 없고, 있으면 안된다. / 그렇다면 App, Presentation 의존성은 대충 관리해도 되는가?

질문에 답이 있다. '나는 왜 DTO를 사용하는가'에 대한 고민을 해본다면, 나에게 맞는 방법이 나올 것이다.

 

 

 

💭 글쓴이는 어떻게 사용하나요?

도메인 메서드는 깔끔하게 유지하고, Application 코드를 조금 더럽게(?) 사용한다.

필드를 까서 넣고있고 [도메인 Dto]는 꼭 필요한 경우에만 Application에서 변환해서 사용한다.

• Request(Command) -> [도메인 Dto] -> 도메인 서비스 전달 
• 도메인 서비스 -> [도메인 Dto] -> Response

그리고 Request, Response를 Application 레이어에 둬서 Presentation의 의존성을 없앴다.

@Transactional
public void write(Long memberId, WriteArticleCommand command) {
    writeArticleProcessor.write(memberId,
        command.getTitle(), command.getContent(),
        command.getImage(), command.getTags());
}

@Transactional(readOnly = true)
public List<ArticlePreviewResponse> findAll(Long articleId, int pageSize) {
    var domainDto = articleReader.findAll(articleId, pageSize);
    
    // 추후 return mapper.toResponse(domainDto); 로 변경.
    return domainDto.stream()
        .map(dto -> new ArticlePreviewResponse(
            dto.getId(), dto.getAuthorId(), dto.getTitle(),
            dto.getNickname(), dto.getImage(), dto.getCreatedAt(),
            dto.getModifiedAt(), dto.getStatus())
        ).collect(Collectors.toList());
}

 

나중에 Application에 Mapstruct같은 매퍼를 사용하면 코드가 깔끔해질 것같다.

 

 

 

사실 제일 사용하고 싶은 방법은 처음에 말했던 코드이긴한데, 사실 나도 잘 모르겠다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/")
public class ItemApiController {
    private final ItemFacade itemFacade; // package.application.ItemFacade
    private final ItemDtoMapper mapper;


    @GetMapping("/register")
    public CommonResponse register(@RequestBody @Valid ItemDto.RegisterItemRequest request) {
        var itemCommand = mapper.toCommand(request); // package.domain.ItemCommand
        var itemInfo = itemFacade.register(itemCommand); // // package.domain.ItemInfo 
        var response = mapper.toResponse(itemInfo); 
        return CommonResponse.success(response); // package.presentation.ItemResponse
    }
}

DTO 사용법에 연연하지 말고,  프로젝트를 계속 만들면서 문제가 생기고 리팩토링 해야할 시점이 왔을 때 하나씩 변경할 생각이다.

 

결국 DTO의 사용방법도 기술에 집착하지말고, 문제를 보라는 것과 동일한 맥락인 듯 하다.

 

💭 레퍼런스

tecoble - DTO의 사용 범위에 대하여

도메인 엔터티를 DTO에 투영하는 더 나은 방법

DDD - which layer DTO should be implemented

Should service layer accept a DTO or a custom request object from the controller?