CH03 도메인 주도 설계 기본 요소

• 전술적 설계를 위한 Entity, Value Object 개념 이해하기

• 전술적 설계를 위한 Aggregate, Repository 개념 이해하기

• 전술적 설계를 위한 도메인 서비스 개념 이해하기

Entity, Value Object 이해하기

Entity

도메인 모델의 메인 빌딩블록은 Entity와 Value Object 라고 할 수 있다. 왜냐하면 도메인 전체를 구조화하고 구체화하는 과정에서 전략적인 수준으로 도메인이 작은 단위로 분류될 수 밖에 없고, 같은 맥락에서 이것의 총합이 곧 도메인이기 때문이다.

이번 수업에서는 모호하게 알고서 사용했던 Entity와 Value Object를 구체적으로 알아보는 과정이었다.

나는 Entity라는 단어 자체를 JPA를 사용하면서 처음 접했는데, 이번에 문득 궁금해서 영어사전을 찾아보니 ‘독립체'라는 뜻이었다. 애초에 Entity라는 단어 자체가 유일성을 가지고 있는 단어였던 것이다. 역시 공부는 한 번 할때 뿌리부터 제대로 알아야 한다는 생각이 들었다.

An entity is something that exists separately from other things and has a clear identity of its own.

독립체이기 때문에 Entity는 이 유일성을 인식하기 위해서 ID 값을 갖는다. 그게 UUID가 되었든, 시퀀스가 되었든 간에 ID 값을 갖는다. 반대로, 유일한 개체로 인식되지 못하는 것은 Entity라고 할 수 없다.

Entity는 아래와 같이 상태값(data)과 행동(method)를 가진다.

https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model

특히 강의에서는 setter의 사용이 도메인의 핵심 개념이나 의도를 코드에서 사라지게 만들기 때문에 setter를 사용해서는 안된다고 했다. 아래는 강의에서 나온 예시이다.

changeShippingInfo() vs setShippingInfo()
completePayment() vs setOrderState()

setter의 사용에 대해서 반대하는 또 한 가지 이유는 setter가 있음으로써 객체가 불완전한 상태로 생성될 수 있다는 것이었다.

프로젝트를 하면서도 Entity를 생성할 때 필요한 데이터를 비워두고 후에 이를 set 한 적이 많은데, ‘불완전한 상태로 생성' 하는 것이 위험성이 있다는 것을 인지를 못했다. 필요한 모든 데이터는 사전에 만들어 둔 뒤에 객체를 생성하는 시점에 완전한 객체로서 생성하는 것이 이상적이다.

Value Object

값객체(Value Object)는 면접 질문에서 자주 나올법한 immutable vs mutable 이슈와 밀접한 연관이 있는 개념이다. 값객체는 객체 자체가 곧 값(value)인 객체이며 그 값은 불변이 원칙이다. 불변이 원칙이란 의미는 값을 변경해야할 일이 있을 경우 아예 객체를 새로 만들어야 한다는 것을 의미한다.

뿐만 아니라 값이 곧 객체로 존재하므로 객체를 생성할 때 필요한 validation 을 넣어주어서 해당 값객체 뿐만 아니라 그 값객체가 속하는 상위 객체의 생성을 더 엄격하게 관리할 수 있다.

시스템이 성숙함에 따라서 데이터를 값객체로 대체한다고 강의자료에 나와있었는데, 시스템을 구축하는 처음 단계부터 최대한 값객체를 활용하면 시스템의 안정성이 높아지지 않을까 생각이 들었다.

아래는 강의자료에 첨부된 값객체를 사용하지 않은 경우의 코드이다. name을 changeName() 을 이용해서 변경할 수 있다.

class Car {
    private String name;
    private int position;
    
    Car(final String name, final int position) {
        if (Objects.isNull(name) || name.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.name = name;
        this.position = position;
    }
    
    void changeName(final String name) {
        if (Objects.isNull(name) || name.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.name = name;
    }
}

다음은 name 이라는 데이터를 값객체로 만든 코드이다. CarName이 값객체이다.

class CarName {
    private final value;
    
    CarName(final String value) {
        if (Objects.isNull(value) || value.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.value = value;
    }
}class Car {
    private CarName name;
    private int position;
    
    Car(final String name, final int position) {
        this.name = new CarName(name);
        this.position = position;
    }
    
    void changeName(final String name) {
        this.name = new CarName(name);
    }
}

한번 생성이 되면 바꿀 수가 없고 변경이 필요할 경우 아예 객체를 새로 할당한다는 측면에서 불변성(immutable)을 지닌다고 할 수 있기에 더 안정적이라고 할 수 있다.

강사님이 이 부분에서 객체를 더 생성하는 만큼 메모리 자원의 낭비가 있지 않냐는 이슈가 충분히 나올 수 있다고 언급 하셨는데, 이에 대해서 일리있는 지적이지만 값객체를 사용하는 장점이 더 크다고 하셨다.

나는 아래 예제에서 값객체의 장점을 더 크게 느꼈다.

class Cash {
    private int dollars;public void mul(int factor) {
        this.dollars *= factor;
    }
}

Cash five = new Cash(5);
five.mul(10);
System.out.println(five);

여기서 보면 five를 mul 하면 dollars는 50이 되는데도 객체의 이름은 five로 머물게 된다. five가 five 가 아닌데도 five라고 표현되어 있는 것이다. 이를 값객체를 이용하면 아래와 같은 코드가 나올 수 있다.

class Cash {
    private final int dollars;public Cash mul(int factor) {
        return new Cash(this.dollars * factor);
    }
}

Cash five = new Cash(5); 
Cash fifty = five.mul(10);
System.out.println(fifty);

이건 Cash 자체가 값객체인 것으로 설명할 수도 있는 예제이면서, 한편으로는 불변성 자체를 설명하기 위한 예시코드로 사용될 수 있는 것 같다.

값을 변경할 때 새로운 객체의 생성을 강제함으로써 fifty라고 명확하게 표현하도록 만들었다.

Aggregate, Repository 개념 이해하기

Aggregate

DDD 학습중에 배운 개념 중 프로그램을 파악하는 가장 러프한 관점이 Bounded Context 단위로 프로그램을 바라보는 것이었다. 러프하다는 개념이 조금 추상적이긴 한데 세부 요구사항, 세부 코드단위까지 갈수록 러프하지 못하다는 의미로 사용해보았다. 즉, Bounded Context는 프로그램을 구성하는 빌딩블록의 단위를 Context단위로 바라보는 것이다.

Aggregate는 합계, 총액이라는 단어인데 이는 Bounded Context에서 한 단계 확대해서 들어가는 것이다. 하나의 Bounded Context 를 이루고 있는 여러 Entity, Value Object 들의 군집이 곧 Aggregate 인 것이다.

강의 자료에서는 아래와 같이 Aggregate를 정의하고 있다.

* 관련 객체를 하나로 묶은 군집 애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.* 애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.* 애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.* 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.* 두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.

여기서 세번째 항목인 ‘애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.’ 의 의미는 하나의 Aggregate에 속한 두 객체가 따로 없어지지 않고 따로 생기지 않는다는 의미이다.

즉, A와 B라는 두 엔티티가 존재하며 이 두 엔티티가 같은 Aggregate에 속한다고 가정했을 때, 두 엔티티 중 하나가 생기면 무조건 다른 하나도 생기게 되며 하나가 없어질때 다른 하나도 없어지는 동일하거나 유사한 라이프 사이클을 갖는다는 것이다.

아래는 강의 자료에서 사용된 Aggregate pattern 의 모습이다.

Order를 보면 Aggregate Root 라고 설명이 적혀 있는데, 강의에서는 root entity 라는 용어로도 사용이 가능하다고 소개되고 있었다. root entity 는 하나의 Aggregate를 대표하는 entity 로 다른 Aggregate 와의 협력이 필요하거나 관계가 맺어질 경우에 Aggregate을 대표해서 역할을 해주는 entity이다.

또한 위 예시에서 본다면 Address나 OrderItem에 뭔가 연산이 필요하게 될 경우 이를 대신하여 요청을 받아 퍼사드하게 처리해주는 entity가 root entity 이며 위 경우에는 Order가 그 역할을 하고 있다.

같은 맥락에서 root entity는 비즈니스 규칙의 일관성을 보장하는 단위이다. 위 예시에서 보면 order와 그 하위 value object 및 entity 의 상태를 order라는 root entity가 대표로 꽉 쥐고 이를 관리하는 것이다. 변화를 관찰하고 비즈니스 규칙에 어긋나는 변화는 허락하지 않는 등 해당 Aggregate이 준수해야할 정책을 root entity가 모두 관장해주어야 한다.

그래서 강의 자료에 나온 위 이미지를 보면 Aggregate 간 소통은 root entity 가 담당해주고 있고, 그 하위 entity 및 value object 들은 root entity 하위에은닉이 잘 되어있는 모습이다.

나는 개인적으로 aggregate과 context가 어떻게 구분되는 개념인지가 확실하게 이해되지 않았는데 아래 이미지를 보니 좀 이해가 편했다.

여기서 보면 네모가 context고 네모에 붙어있는 동그라미가 aggregate이다. context가 더 큰 개념이라고 볼 수 있고, 하나의 context에는 하나 혹은 그 이상의 aggregate이 속할 수 있다.

Repository

DDD의 repository와 JPA에서 일반적으로 사용하던 repository는 책임과 역할의 범위가 조금 다르다. JPA가 entity 단위였다면 DDD의 repository는 Aggregate 단위로 repository를 만든다. Aggregate 단위의 repository가 aggregate의 원자성을 보장하게 된다.

도메인 서비스 개념 이해하기

도메인 서비스는 하나의 aggregate만으로 처리가 힘든 경우의 ‘도메인 로직' 을 처리해주는 ‘행위’만 가진 서비스이다. 즉, 여러 aggregate간의 협력이 필요한 도메인 로직을 수행해주며 이로써 도메인 로직이 어플리케이션 로직으로 침범하는 것을 막아주는 일종의 방파제 역할을 한다.

도메인 서비스와 어플리케이션 서비스 간의 경계 구분이 힘든 경우, 강의 자료에 나온 아래 지침을 통해서 판단을 하면 좋을 것 같다.

* 특정 기능이 응용 서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해 보면 된다.* 서비스를 사용하는 주체는 애그리거트가 될 수도 있고 응용 서비스가 될 수도 있다.

강의에서 설명하듯 할인 정책, 배송 정책 등 따로 컨플루언스로 정리해놓은 법한 비즈니스 규칙들이 도메인 서비스로 관리되어야 할 규칙들이라고 보면 된다.

미션을 수행하다가 리뷰어님이 도메인 서비스에는 커스텀한 어노테이션을 만들어준다고 조언해주셔서 나도 반영해보았는데 괜찮은 것 같다. 어플리케이션 서비스와 도메인 서비스 둘다 ~service이기 때문에 이를 구분하기 좋게 어노테이션부터 구분하고 클래스 명도 구분해주면 코드가 더 명확해진다.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface DomainService {
}

위와 같이 커스텀한 어노테이션을 만들어주고, 아래와 같이 도메인 서비스에 어노테이션을 사용함과 동시에 클래스명도 다르게 설정해줬다.

@DomainService
public class MenuValidator {

    private final MenuGroupRepository menuGroupRepository;
    private final ProductRepository productRepository;

    public MenuValidator(MenuGroupRepository menuGroupRepository, ProductRepository productRepository) {
        this.menuGroupRepository = menuGroupRepository;
        this.productRepository = productRepository;
    }

    public void validateMenu(Menu menu) {
        menuGroupRepository.findById(menu.getMenuGroupId()).orElseThrow(() -> new IllegalArgumentException("메뉴는 특정 메뉴 그룹에 속해야 합니다."));
    }

    public void validateMenuProducts(List<MenuProduct> menuProducts) {
        menuProducts
                .forEach(menuProduct -> productRepository.findById(menuProduct.getProductId()).orElseThrow(() -> new IllegalArgumentException("등록되지 않은 상품이 포함되어 있습니다.")));
    }

}

실습코드

GitHub - fistkim101/ddd-tactical-design at fistkim101GitHub