이건 별로일까?

Kim Dong Kyun·2024년 6월 20일
2
public record PostRequestDto(
        String continent,
        String country,
        LocalDateTime tripStartDate,
        LocalDateTime tripEndDate,
        String title,
        String content,
        List<String> shortPosts
) {
    public Post toEntity(Member member) {
        return new Post(continent, tripStartDate, tripEndDate, title, content, member, country);
    }
    
    public void updatePostEntity(Post post){
        post.updateFields(
                country,
                tripStartDate,
                tripEndDate,
                title,
                content
        );
    }
}
  1. 레이어적으로는 하위 레이어의 공개된 인터페이스(updateFields 매서드) 를 상위 레이어 (service레이어의 Dto) 가 사용하므로 "사용은 가능" 하다
  2. 그런데, 조금 찝찝하다. service에서 해야 하는 일은 아닐까? 어떤 필드가 업데이트 되는지 service에서 보여주는 게 더 명시적일까?

여러분의 생각은?

1개의 댓글

comment-user-thumbnail
2024년 6월 20일

내 생각

  1. 서비스의 역할에 위배
    서비스의 역할은 다양한 도메인 로직의 흐름을 연결시키는 역할이다. (도메인간의 상호작용의 결과를 만들어내는 객체)

따라서 서비스 클래스의 역할이 충실히 이행되려면 update 로직 자체가 서비스 클래스에서 온전히 이루어 지는 것이 좀 더 이해나 관리가 쉬울 것이다.

  1. 한 단계 더 추상화 할 시 가져오는 불편함 (귀찮음)

DIP 를 고려하면, 로직의 제어권 흐름은
엔티티 -> 디티오 -> 서비스 -> 컨트롤러
가 된다.

제어권을 디티오에게 가지게 할 합당한 이유가 없다. 디티오는 서비스 레이어(어플리케이션 레이어) 에 속하지만, 이 객체의 역할은 단순 데이터의 운반이다.

따라서 업데이트 로직이 복잡할수록 디티오마다 관리해야 할 포인트가 늘어나게 될 것이고(제어권을 서비스가 아닌 여러 개의 디티오가 가지므로) 따라서 비효율적(귀찮)이다.

답글 달기