인프런 커뮤니티 질문&답변

안녕하세요 권기준 님, 인프런 AI 인턴이에요.

1. 서비스 클래스와 리포지토리 클래스를 분리하는 이유는 결합도를 낮추기 위해서입니다. 결합도가 낮으면 각각의 클래스가 독립적으로 변경 가능하고 유연하게 확장할 수 있습니다. 즉, 서비스 클래스가 리포지토리 클래스의 내부 구현에 종속되지 않고, 리포지토리 클래스도 서비스 클래스의 변경을 신경 쓸 필요가 없도록 합니다.

2. 분리된 도메인 클래스로 변환하는 작업은 가독성을 해치지 않습니다. 실제로는 변환 작업이 진행되지만, 이 작업은 도메인 클래스 자체에서 수행되기 때문에 서비스 클래스의 메서드 구현이 길어지는 일은 발생하지 않습니다. 도메인 클래스는 비즈니스 로직을 포함하고, 데이터 변환과 관련된 로직을 가지고 있을 수도 있습니다.

3. 보편적으로는 도메인 클래스를 생성하고 변환하여 비즈니스 로직을 처리하는 방식을 많이 사용합니다. 이는 도메인 클래스 내에 비즈니스 규칙과 연관된 로직을 집중시키고, 외부와의 인터페이스에는 DTO 객체를 사용하여 필요한 데이터만 전달하는 것이 좋은 설계 원칙이기 때문입니다. 또한, DTO 객체를 사용하면 클라이언트와의 데이터 통신에 중복된 필드를 제어할 수 있습니다.

위의 설명이 도움이 되셨길 바랍니다. 질문이 무례하지 않습니다. 언제든지 궁금한 점이 있으시면 편하게 질문해 주세요. 감사합니다!

안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.

AI가 답변을 잘 달아줬네요. AI 답변에 보충 설명이 있으면 좋을 것 같아 답을 답니다.

1. 이렇게 분리하는 이유는 서로의 결합을 낮추기 위해서인가요?

네 맞습니다. 결합을 낮추기 위함입니다.

1. 서비스에 도메인 클래스 변환 로직

서비스에 도메인 클래스로 변환하는 로직이 들어가면 안 됩니다. 왜냐하면 이렇게 될 경우 결국 서비스가 JpaEntity를 알게 되기 때문입니다. 도메인 클래스로 변환하는 로직은 영속성 객체 쪽에 들어가는 것이 조금 더 자연스럽습니다. 이는 다음과 같이 코드를 만들 수 있다는 말입니다.

@Data
@Entity("member")
public class MemberEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    private String name;

    // MemberEntity를 Member 모델로 변환하는 메서드
    public Member toModel() {
        return new Member(id, name);
    }

    // Member 모델을 MemberEntity로 변환하는 정적 메서드
    public static MemberEntity from(Member member) {
        MemberEntity memberEntity = new MemberEntity();
        memberEntity.id = member.getId();
        memberEntity.name = member.getName();
        return memberEntity;
    }
}

이런 식으로 도메인 변환 로직을 영속성 객체가 들고 있게 할 수 있습니다. Repository에서 from, toModel 메서드를 사용하도록 하고요. 이러면 서비스 코드의 가독성을 헤치지 않을 수 있습니다.

2번 질문에 후속으로 달아준 의견은 제가 이해를 잘못해서 답변을 드리기 어렵네요…😭

어떻게 하라는 것인지 그래도 헷갈린다면 이쪽 샘플 코드를 확인해 주면 좋을 것 같습니다. (https://github.com/kok202/test-code-with-architecture/tree/v2.0) 후속 강의에서 사용하는 예제 코드인데, 본 강의에서 추구하는 프로젝트의 구조는 위 레포지토리의 v2.0 태그 코드입니다.

답변이 도움 됐길 바랍니다.