도메인 변환 메서드 통일.md

💡 도메인 변환 메서드 통일

방법 1️⃣: 서비스 코드 중간에서 직접 빌더 사용

SemanticOption semanticOption = SemanticOption.builder()
                .leftEnd(semanticOptionRequest.leftEnd())
                .rightEnd(semanticOptionRequest.rightEnd())
                .question(question)
                .build();

• 장점 🌟: 엔티티 내부 로직 단순.
• 단점 ⚠️: 서비스 코드 길어짐.

방법 2️⃣: 요청 객체 내부에 변환 메서드

public class TemplateRequestDto {
		...
    public TemplateDomain toTemplateDomain(Long id) {
        return TemplateDomain.builder()
                .id(id)
                .templateColumn1(templateColumn1)
                .templateColumn2(templateColumn2)
                .build();
    }
}

• 장점 🌟: 서비스 로직 단순화.
• 단점 ⚠️: 각 DTO에 변환 함수 필요.

방법 3️⃣: 도메인 내부에 요청 객체를 받는 생성자

@Entity
public class User {
    
    public User(JoinRequest joinRequest) {
        this.name = joinRequest.name();
        this.email = joinRequest.email();
    }
}

• 장점 🌟: 반복적인 객체 생성 코드 필요 없음.
• 단점 ⚠️: 엔티티가 복잡해짐.

방법 4️⃣: 팩토리 패턴 사용

Option option = OptionFactory.makeOption(optionRequest)
//makeOption 내부에 semanticOption를 만드는 로직 포함

• 장점 🌟: 반복적인 객체 생성 코드 제거.
• 단점 ⚠️: 추가적인 클래스 복잡도 증가.

🗣 멘토님의 조언

• 통일이 필수 🔄. 1번을 제외한 어떠한 방식을 사용해도 괜찮음.
  • 별도의 Mapper 클래스를 만들어 변환 로직을 관리하는 것을 가장 선호함. 하지만, 1번을 제외한 어떠한 방식을 사용해도 괜찮음.

public class MemberMapper {
    public static MemberDto toDto(Member member) {
        // 변환 로직
    }

    public static Member toEntity(MemberDto memberDto) {
        // 변환 로직
    }
}

💡 팀 결론

투표를 통해 도메인 내부에 요청 객체를 받는 생성자 를 사용하기로 결정