[Domain Driven Design] 6. 도메인 영역의 구성요소 (엔티티, 밸류, 애그리거트, 리포지토리)

구성요소

도메인 영역은 도메인의 핵심 모델을 구현한다. 도메인 영역의 모델은 도메인의 주요 개념을 표현하며 핵심 로직을 구현한다. 

 

도메인 영역을 구성하는 요소

요소		설명
엔티티	ENTITY	고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.
밸류	VALUE	고유의 식별자를 갖지 않는 객체로 주요 개념적으로 하나의 값을 표현할때 사용된다. 배송지 주소를 표현하기 위한 주소나 구매 금액을 위한 금액와 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다.
애그리거트	AGGREAGATE	애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를들어, 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 '주문' 애그리거트로 묶을 수 있다.
리포지터리	REPOSITORY	도메인 모델의 영속성을 처리한다. 예를들어, DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.
도메인 서비스	DOAIN SERVICE	특정 엔티티에 속하지 않은 도메인 로직을 제공한다.  '할인 금액 계산'은 상품, 쿠폰, 회원 등급, 구매 그므액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

 

 

엔티티와 밸류

실제 도메인 모델의 엔티티와 DB 관계형 모델의 엔티티는 같은 것이 아니다. 이 두 모델의 가장큰 차이점은 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다는 것이다. 

예를들어, 주문을 표현하는 엔티티는 주문과 관련된 데이터뿐만 아니라 배송지 주소 변경을 위한 기능을 함께 제공한다.

 

Order.java

package com.myshop.order.command.domain;

import com.myshop.common.event.Events;
import com.myshop.common.jpa.MoneyConverter;
import com.myshop.common.model.Money;

import javax.persistence.*;
import java.time.LocalDateTime;
import java.util.List;

public class Order {
    private OrderNo number;
    private long version;
    private Orderer orderer;
    private ShippingInfo shippingInfo;

    protected Order() {
    }

    ...
    
    public void changeShippingInfo(ShippingInfo newShippingInfo) {
        verifyNotYetShipped();
        setShippingInfo(newShippingInfo);
        Events.raise(new ShippingInfoChangedEvent(number, newShippingInfo));
    }
}

도메인 모델의 엔티티는 단순히 데이터를 담고 있는 데이터 구조라기보다는 데이터와 함께 기능을 제공하는 객체이다.

도메인 관점에서 기능을 구현하고 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.

 

▶ 또 다른 차이점

도메인 모델의 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해서 표현할 수 있다는 것이다. 위 코드에서 주문자를 표현하는 Order는 밸류 타입으로 다음과 같이 주문자 이름과 이메일 데이터를 포함할 수 있다.

public Class Orderer {
    private String name;
    private String eail;
    
    ...
}

 

이와 다르게 DBMS와 같은 관계형 데이터베이스는 밸류 타입을 제대로 표현하기 힘들다. Order 객체의 데이터를 저장하기 위한 테이블은 Orderer의 개별 데이터를 저장하거나 별도 테이블로 분리해서 저장해야한다. 

 

밸류는 불변으로 구현할 것을 권장하며, 엔티티의 밸류 타입 데이터를 변경할 때는 객체 자체를 완전히 교체한다는 것을 의미한다. 예를들어 배송지 정보를 변경하는 코드는 기존 객체의 값을 변경하지 않고 새로운 객체에 필드에 할당한다.

 

Order.java

package com.myshop.order.command.domain;

import com.myshop.common.event.Events;
import com.myshop.common.jpa.MoneyConverter;
import com.myshop.common.model.Money;

import javax.persistence.*;
import java.time.LocalDateTime;
import java.util.List;

public class Order {
    private OrderNo number;
    private long version;
    private Orderer orderer;
    private ShippingInfo shippingInfo;

    protected Order() {
    }

    ...
    
    public void changeShippingInfo(ShippingInfo newShippingInfo) {
        verifyNotYetShipped();
        setShippingInfo(newShippingInfo);
        Events.raise(new ShippingInfoChangedEvent(number, newShippingInfo));
    }
    
    private void setShippingInfo(ShippingInfo shippingInfo) {
        if (shippingInfo == null) throw new IllegalArgumentException("no shipping info");
        this.shippingInfo = shippingInfo;
    }
}

 

 

애그리거트

도메인이 커질수록 개발할 도메인 모델도 커지면서 많은 엔티티와 밸류가 출현한다.

엔티티와 밸류 개수가 많아질수록 모델은 점점 더 복잡해진다.

https://minkukjo.github.io/dev/2020/11/02/DDD-02/

도메인 모델이 복잡해지면, 개발자가 전체 구조가 아닌 한개 엔티티와 밸류에만 집중하는 상황이 발생한다. 이때 상위 수준에서 모델을 관리하지 않고 개별 오소에만 초점을 맞추다보면, 큰 수준에서 모델을 이해하지 못해 큰 틀에서 모델을 관리할 수 없는 상황에 빠질 수 있다.

 

도메인 모델은 개별 객체 뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는데 도움이 된다. 도메인 모델에서 전체 구조를 이해하는데 도움이 되는 것이 '애그리거트(AGGREGATE)'이다.

https://devlos.tistory.com/51

▶ 군집 단위 

애그리거트는 관련 객체를 하나로 묶은 군집이다. 애그리거트의 대표적인 예가 주문이다. 주문이라는 도메인 개념은 '주문', '배송지 정보', '주문자', '주문 목록', '총 결제 금액'의 하위 모델로 구성된다.

이 하위 개념을 표현한 모델을 하나로 묶어서 '주문'이라는 상위 개념으로 표현할 수 있다.

 

애그리거트를 사용하면 개별 객체가 아닌 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 된다. 개별 객체 간의 관계가 아닌 애그리거트 간의 관계로 도메인 모델을 이해하고 구현하게되며, 이를 통해 큰 틀에서 도메인 모델을 관리할 수 있다.

 

애그리거트는 군집에 속한 객체를 관리하는 루트 엔티티를 갖는다. 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다. 애그리거트를 사용하는 코드는 액리거트 루트가 제공하는 기능을 실행하고 애그리거트 루트를 통해서 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근한다. 이것은 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다. 

 

Order.java

public class Order {
    ...
    
    public void changeShippingInfo(ShippingInfo newInfo) {
        checkShippingInfoChangeable(); // 배송지 변경 가능 여부 확인 
        this.shippingInfo = newInfo;
    }
    
    private void checkShippingInfoChangeable() {
        ... 배송지 정보를 변경할 수 있는지 여부를 확인하는 도메인 규칙 구현
    }
}

 

checkShippingInfoChangeable() 메서드는 도메인 규칙에 따라 배송지를 변경할 수 있는지 확인한다. 

 

주문 애거리거트는 Order를 통하지 않고 ShippingInfo를 변경할 수 있는 방법을 제공하지 않는다. 즉, 배송지를 변경하려면 루트 엔티티인 Order를 사용해야 하므로 배송지 정보를 변경할 때에는 Order가 구현한 도메인 로직을 항상 따르게 된다.

 

애그리거트를 구현할 때는 고려할 것이 많다. 애그리거트를 어떻게 구성했느냐에 따라 구현이 복잡해지기도 하고, 트랜잭션 범위가 달라지기도 한다. 또한 선택적 구현 기술에 따라 애그리거트 구현에 제약이 생기기도 한다.

 

 

리포지터리

도메인 객체를 지속적으로 사용하려면 RDBMS, NoSQL, 로컬 파일과 같은 물리적인 저장소에 도메인 객체를 보관해야 한다.  이를 위한 도메인 모델이 리포지터리(Repository)이다. 엔티티나 밸류가 요구사항에서 도출되는 도메인 모델이라면 리포지터리는 구현을 위한 도메인 모델이다.

 

리포지터리는 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다. 예를들어 주문 애그리거트를 위한 리포지터리는 다음과 같이 정의할 수 있다.

 

OrderRepository.java

package com.myshop.order.command.domain;

import org.springframework.data.repository.Repository;

import java.util.Date;
import java.util.Optional;
import java.util.concurrent.ThreadLocalRandom;

public interface OrderRepository extends Repository<Order, OrderNo> {
    Optional<Order> findById(OrderNo id);

    void save(Order order);
	
    ...
}

OrderRepository의 메섣를 보면 대상을 찾고 저장하는 단위가 액리거트 루트인 Order인 것을 알 수 있다. Order는 애그리거트에 속한 모든 객체를 포함하고 있으므로 결과적으로 애그리거트 단위로 저장하고 조회한다.

 

도메인 모델을 사용해야 하는 코드는 리포지토리를 통해서 도메인 객체를 구한 뒤에 도메인 객체의 기능을 실행한다. 예를들어, 주문 취소 기능을 제공하는 응용 서비스는 다음 코드처럼 OrderRepository를 이용해서 Order 객체를 구하고 해당 기능을 실행한다.

 

CancelOrderService.java

package com.myshop.order.command.application;

import com.myshop.order.NoOrderException;
import com.myshop.order.command.domain.*;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class CancelOrderService {
    private OrderRepository orderRepository;

    @Transactional
    public void cancel(OrderNo orderNo, Canceller canceller) {
        Order order = orderRepository.findById(orderNo)
                .orElseThrow(() -> new NoOrderException());
        if (!cancelPolicy.hasCancellationPermission(order, canceller)) {
            throw new NoCancellablePermission();
        }
        order.cancel();
    }

}

 

도메인 모델 관점에서 OrderRepository는 도메인 객체를 영속화하ㄴㄴ데 필요한 기능을 추상화한 것으로 고수준 모듈에 속한다.

기반 기술을 이용해서 OrderRepository를 구현한 클래스는 저수준 모듈로 인프라스트럭처 영역에 속한다. 즉 전체 모듈 구조는 아래의 그림과 같다.

https://minkukjo.github.io/dev/2020/11/02/DDD-02/

 

응용 서비스는 의존 주입과 같은 방식을 사용해서 실제 리포지터리 구현 객체에 접근한다. 

응용 서비스와 리포지터리는 밀접한 연관이 있다. 그 이유는 다음과 같다.

• 응용 서비스는 필요한 도메인 객체를 구하거나 저장할때 리포지토리를 사용한다.
• 응용 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술의 영향을 받는다.

 

리포지터리를 사용하는 주체가 응용 서비스이기 때문에 리포지터리는 응용 서비스가 필요로하는 메서드를 제공한다. 다음 두 메서드가 기본이 된다.

• 애그리거트를 저장하는 메서드
• 애그리거트 루트 식별자로 애그리거트를 조회하는 메서드

이 두 메서드는 다음 형태를 갖는다.

public interface SomeRepository {
    void save(Some some);
    Some findById(SomeId id);
}