도메인과 요청의 검증 로직의 분리

[Dr-KoKo]

Note

PR #12 에서 파생된 논의 입니다

AS-IS

public Vendor(String name, String email, String password, String phone, PayAccount payAccount,
		PasswordEncoder passwordEncoder) throws InvalidCreationException {
		checkName(name);
		checkEmail(email);
		checkPassword(password);
		checkPhone(phone);
		checkPayAccount(payAccount);
		this.name = name;
		this.email = email;
		this.password = passwordEncoder.encode(password);
		this.phone = phone;
		this.payAccount = payAccount;
	}

	private void checkPayAccount(PayAccount payAccount) throws InvalidCreationException {
		if (payAccount == null) {
			throw new InvalidCreationException("Pay account cannot be null");
		}
	}

	private void checkPhone(String phone) throws InvalidCreationException {
		if (phone == null || phone.isBlank()) {
			throw new InvalidCreationException("Vendor phone cannot be blank");
		}
		if (phone.trim().length() > 30) {
			throw new InvalidCreationException("Vendor phone cannot be longer than 30 characters");
		}
	}

	private void checkPassword(String password) throws InvalidCreationException {
		if (password == null || password.isBlank()) {
			throw new InvalidCreationException("Vendor password cannot be blank");
		}
		if (password.trim().length() < 8 || password.trim().length() > 30) {
			throw new InvalidCreationException(
				"Vendor password must be at least 8 characters and at most 30 characters");
		}
	}

	private void checkEmail(String email) throws InvalidCreationException {
		if (email == null || email.isBlank()) {
			throw new InvalidCreationException("Vendor email cannot be blank");
		}
		if (email.trim().length() > 100) {
			throw new InvalidCreationException("Vendor email cannot be longer than 100 characters");
		}
	}

	private void checkName(String name) throws InvalidCreationException {
		if (name == null || name.isBlank()) {
			throw new InvalidCreationException("Vendor name cannot be blank");
		}
		if (name.length() > 50) {
			throw new InvalidCreationException("Vendor name cannot exceed 50 characters");
		}
	}

TO-BE

public record SignUpVendorCommand(
        @NotNull @NotBlank
    String name,

        @NotNull @NotBlank
    String email,

        @NotNull @NotBlank
    String password,

        @NotNull @NotBlank
    String phone
) {
}

// pseudo code
public class VendorValidator {

  public void validate(name, email, password, phone) {
    validateName(name);
    validateEmail(email);
    validatePassword(password);
    validatePhone(phone);
  }

  private void validateName(name) { ... };
  private void validateEmail(email) { ... };
  private void validatePassword(password) { ... };
  private void validatePhone(phone) { ... };
}

[참고] 우아한형제들 기술블로그 의 피드백1

[june-777]

도메인 객체 검증에 대한 논의

도메인 객체의 검증을 어디서 수행하는게 적절할지 논의하고자 합니다.

논의1. Null값, 빈값에 대한 검증

1. null, isBlank 검증은 요청DTO (SignUpVendorCommand) 에서 Bean Validation으로 검증하는 것은 어떨까요?

• Null값, 공백포함 빈값을 모든 도메인마다 검증하면 중복 코드가 많이 발생할 것 같아요.

• 그리고 도메인 검증은 비즈니스 요구사항에 대한 검증을 하는게 좋다고 생각하는데요, Null값과 빈값은 비즈니스 요구사항보단 기본적인 입력값에 대한 검증이라는 생각이 들어요.

• 아래와 같이 요청 DTO에서 입력값에 대한 검증을 수행하면, 도메인 객체는 비즈니스 요구사항에 조금 더 집중할 수 있는 장점이 있을거라 생각해요 :)

  public record SignUpVendorCommand(
          @NotNull @NotBlank
      String name,
  
          @NotNull @NotBlank
      String email,
  
          @NotNull @NotBlank
      String password,
  
          @NotNull @NotBlank
      String phone
  ) {
  }

논의2. Null값, 빈값 이외의 값들에 대한 검증

2. VendorValidator 클래스에게 Vendor 검증로직을 위임하는건 어떨까요?

• Null값, 빈값 이외의 검증은 지금처럼 도메인 객체에서 검증해도 좋다고 생각해요. 다만, 검증 로직이 많아질 경우 검증에 대한 분리를 고민해봐도 좋을 것 같아요.
  도메인 객체는 비즈니스 요구사항이 응집되어 있는 객체인데, 검증 로직이 너무 많아지다보면 검증을 위한 객체인지 비즈니스를 위한 객체인지 분간이 어려워질 수 있다고 생각했어요. 우아한형제들 기술블로그 의 피드백1을 참고해봐도 좋을 것 같아요 :)

• 아래와 같이 리팩터링하면, 도메인 객체는 순수하게 비즈니스 요구사항만을 담고 있게 되는 장점이 있을 것 같아요 :)

  // pseudo code
  public class VendorValidator {
  
    public void validate(name, email, password, phone) {
      validateName(name);
      validateEmail(email);
      validatePassword(password);
      validatePhone(phone);
    }
  
    private void validateName(name) { ... };
    private void validateEmail(email) { ... };
    private void validatePassword(password) { ... };
    private void validatePhone(phone) { ... };
  }

[Hyeon-Uk]

@june-777 이슈에 달았던 의견을 여기에 업데이트 하겠습니다!

• null, isBlank 검증은 요청DTO (SignUpVendorCommand) 에서 Bean Validation으로 검증하는 것은 어떨까요?

  • 이 말의 의미가 도메인 엔티티 생성자에서의 null과 isBlank 검증에 대한 책임을 DTO로 전가하자는 의미인가요?
  • 만약 위의 의견이 맞다면 저는 DTO와 Domain에 대해서 필수적으로 Double Checking 해주는것이 맞다고 생각해요
  • 만약 해당 도메인을 사용하기 위해 생성한 다른 DTO에서 실수로 검증하지 않게되면 Domain 객체에서 예상치 못한 exception을 발생시킬 수 있기 때문이라 생각해요

• Null값, 공백포함 빈값을 모든 도메인마다 검증하면 중복 코드가 많이 발생할 것 같아요.

  • 중복 코드에 대해서는 Discussion 도메인과 요청의 검증 로직의 분리 #17 에서 논의하면 좋은 구조가 도출될거 같아요!

• 그리고 도메인 검증은 비즈니스 요구사항에 대한 검증을 하는게 좋다고 생각하는데요, Null값과 빈값은 비즈니스 요구사항보단 기본적인 입력값에 대한 검증이라는 생각이 들어요.

  • 기본적인 입력값이라고 생각이 될 수 있겠지만, 저는 Domain 생성자의 입력값 검증 또한 비즈니스 요구사항이라고 생각해요!

결론적으로

Domain 생성자의 입력값 검증 또한 비즈니스 요구사항이기 때문에, 검증에 대한 책임을 DTO로 넘기지 말고 Double Checking하는 방향으로 가져갔으면 좋겠습니다 라는 의견입니다 :)

[Dr-KoKo]

24-08-12 회의 내용입니다.

도메인에서 Null 검증이 필요한가

• 값이 그대로 DB에 저장되기 때문에 설사 표현영역에서 검증을 했더라도 더블 체킹이 필요하다.

어떻게 검증할 것인가?

• @Phone 검증 ?
• Domain 객체는 DomainValidator 에서 절차지향으로 검증
• 핸드폰 번호 같이 애매한 부분은 각자 스타일에 맞게 구현하고, PR에서 토의
  • @Phone 검증

결론

• 도메인에서 생성 파라미터에 대한 검증을 수행한다.
• DomainValidator 에서 절차지향으로 검증한다.
• 구체적인 구현은 각자에게 맡기고 이후의 PR을 통해 추가적으로 논의한다.