Request DTO에서 Entity를 생성할 때 의존성 방향을 반대로 하면 어떨까요?

안녕하세요.

Member 객체를 생성할 때, 다른 방법을 선택해 보는 것은 어떨까요?

기존에는(설계 트레이드 오프 개선 전) Member.register()가 MemberRegisterRequest에 직접 의존하고 있었는데, 도메인 모델이 요청 DTO를 알지 않도록 의존성을 반대로 두는 방법입니다.

MemberRegisterRequest에서 Member 객체를 직접 생성하는거죠.

public record MemberRegisterRequest(
    ...
) {

    public Member toMember(PasswordEncoder passwordEncoder) {
        return Member.register(email, nickname, password, passwordEncoder);
    }
}

public class Member extends AbstractEntity {
    ...
    public static Member register(String email, String nickname, String password, PasswordEncoder passwordEncoder) {
        Member member = new Member();
        member.email = new Email(email);
        member.nickname = requireNonNull(nickname);
        member.passwordHash = requireNonNull(passwordEncoder.encode(password));
        member.status = MemberStatus.PENDING;

        member.detail = MemberDetail.create();

        return member;
    }
    ...
}

public class MemberModifyService implements MemberRegister {
    ...
    @Override
    public Member register(MemberRegisterRequest registerRequest) {
        checkDuplicateEmail(registerRequest);

        Member member = registerRequest.toMember(passwordEncoder);
        memberRepository.save(member);

        sendWelcomeEmail(member);
        return member;
    }
    ...
}

MemberRegisterRequest.toMember(passwordEncoder)에서 Member.register(email, nickname, password, passwordEncoder)를 호출하면 Request DTO → Domain 방향으로만 의존합니다. 별도의 MemberRequestInfo 같은 파라미터 객체도 필요하지 않아 구현이 단순합니다.

Request DTO를 단순 데이터 전달 객체로 유지하려면 서비스 계층에서 각 값을 꺼내 Member.register()에 전달하는 방법도 가능합니다. (이 방법보다는 이전 방법이 서비스 계층을 간결하게 유지하는 방법이긴 합니다.)

이런 방법을 기본 개발 규칙으로 두면, 의존성 방향도 문제 없고, 추가적인 객체(예: MemberRequestInfo)를 생성할 필요도 없어서 충분한 이점이 있습니다.

다만, register()에 전달해야 할 파라미터가 많아진다면 번거롭긴 하겠네요.

이 방법에 대한 의견도 부탁 드립니다.

감사합니다.