<aside>

DTO는 단순히 데이터를 전달하는 역할인가?

• Controller → Service로 넘길 때, 모든 데이터를 다 넘겨도 될까? (유지보수성을 늘리기 위해 우리는 어떤 구조로 틀을 짤 수 있을까.)
• Entity에서 노출되지 않아야 할 정보는 어떻게 걸러내야 할까? (즉, 엔티티 자체가 DTO에 대한 정보를 들고 있어도 될까.) </aside>

createPost 함수에서 postService에 postCreateRequest를 그대로 넘기고 있다.

하지만 여기서 postCreateRequest에 들어가는 내용은 non-nullable한 2가지(title, content)이므로 모든 데이터를 넘겨도 괜찮다고 판단했다.

@RestController
@RequestMapping(value = "/board")
public class PostController {
    private final PostService postService;

    protected PostController(PostService postService) {
        this.postService = postService;
    }

    @PostMapping()
    public BaseResponse<?> createPost(
            @RequestHeader Long userId,
            @Valid @RequestBody final PostCreateRequest postCreateRequest
    ) {
        postService.createPost(userId, postCreateRequest);
        return BaseResponse.success(SuccessMessage.CREATED);
    }
...

하지만 일부만 변경하거나 일부의 데이터만 필요할 때는 Command Pattern 을 이용하는 것이 좋다고 한다.

• 어떤 필드가 변경되는지 명확히 할 수 있음
• Service가 어떤 데이터를 활용하는지 명시할 수 있음
• 불필요한 데이터를 넘기지 않아도 됨

    @PatchMapping("/{post-id}")
    public BaseResponse<PostResponse> updatePostTitle(
            @RequestHeader Long userId,
            @PathVariable("post-id") Long postId,
            @RequestBody final PostTitleUpdateRequest postTitleUpdateRequest
    ) {
        return BaseResponse.success(SuccessMessage.OK, postService.updatePostTitle(userId, postId, postTitleUpdateRequest.title()));
    }

위 updatePostTitle 함수의 경우 postTitleUpdateRequest.title() 로 Service 계층에 필요한 정보만 넘기고 있다.

이렇게 넘겨도 되는 걸 왜 굳이 Command Pattern 을 이용해야 할까?

현재는 파라미터가 적어서 괜찮지만, 실제 서비스에서는 파라미터가 굉장히 많아지기 때문에 Command 객체로 묶어주기 위함이다.

VO(Value Object)는 무엇일까? 왜 사용할까?