도메인 주도 설계 구현

엔터티(entity)

엔터티의 발견과 그들의 내부적인 특징

유효성 검사

모델 내의 유효성 검사를 사용하는 주 이유는 하나의 특성/속성, 전체 객체, 객체의 컴포지션 등의 정확성을 확인하기 위해서다

우리는 하나 이상의 단계로 이뤄진 유효성 검사를 통해 가능한 모든 문제를 다뤄야 한다.

특성/속성의 유효성 검사

하나의 특성이나 속성을 비유효한 값의 설정으로 보호하는 방법은 무엇일까? 자가 캡슐화를 사용을 강력히 추천한다.

1 2	자가 캡슐화는 심지어 같은 클래스 내에서부터 모든 데이터로의 액세스가 접근자 메소드를 거쳐가도록 설계하는 방법이다. [마틴 파울러]

자가 캡슐화를 사용해 올바른 객체 상태를 보호하는 과정을 유효성 검사라 부르길 좋아하지 않는다.
유효성 검사는 도메인 객체가 아닌 유효성 검사 클래스의 책임이어야 하는것 이라 생각해서 이다.

아래는 계약에 의한 설계 접근법 측면의 assertion 이다.


package com.github.sejoung.ddd.chapter5;

import org.springframework.util.StringUtils;

public final class EmailAddress {

    private String address;

    public EmailAddress(String address) {
        this.setAddress(address);
    }

    private void setAddress(String address) {

        if (StringUtils.isEmpty(address)) {
            throw new IllegalArgumentException("address 값이 비었다.");
        }

        if (address.length() > 100) {
            throw new IllegalArgumentException("address 값이 100자를 초과하면 안된다.");
        }
        this.address = address;

    }
}

클래스 EmailAddress는 엔터티가 아니다. 이는 값 객체다. 일부 개발자는 이런 종류의 전제 조건 확인을 방어적 프로그래밍이라 부른다.

위처럼 코딩 하지 않고 100자리를 초과한 입력에서 dbms 오류를 그대로 내보내면 어떤 열이 초과 된지도 알수가 없다.

전체 객체의 유효성 검사

전체 객체 검사의 유용한 방법은 지연 유효성 검사이다.

객체 컴포지션의 유효성 검사

지연 유효성 검사를 통해 하나이상의 객체 컴포지션을 확인 한다.

변화 추적

엔터티의 정의에 따라 수명주기에 걸쳐 일어나는 모든 상태 변경을 추적할 필요는 없다.
우리는 오직 계속 변화하는 상태만을 지원해야 한다.

도메인 전문가가 모델에서 일어난 모든 변화를 신경 쓰진 않을지라도, 기술 팀에 관심을 가질 수도 있다.