[ DDD ] 03. 애그리거트

DDD

[ DDD ] 03. 애그리거트

솔솔 2023. 5. 2. 15:00

이 게시글은 "도메인 주도 개발 시작하기 : DDD 핵심 개념 정리부터 구현까지" 최범균 님의 책을 기반으로 작성하였습니다.

[ DDD ] 02. 아키텍처 개요

이 게시글은 "도메인 주도 개발 시작하기 : DDD 핵심 개념 정리부터 구현까지" 최범균 님의 책을 기반으로 작성하였습니다. [DDD] 01. 도메인 모델 시작하기 이 게시글은 "도메인 주도 개발 시작하기

ddol.tistory.com

애그리거트

애그리거트는 관련된 객체를 하나의 군으로 묶어 준다.
수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.
복잡한 도메인을 단순한 구조로 만들어준다.
복잡도가 낮아지는 만큼 도메인 기능을 확장하고 변경하는 데 필요한 노력 (개발 시간)도 줄어든다.
애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
- ex) 주문 애그리거트를 만들려면 Order, OrderLine, Orderer와 같은 관련 객체를 함께 생성해야 한다.
애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
- ex) 주문 애그리거트가 생성 될 때 Order만 생성되고 OrderLine, Orderer이 생성되지 않으면 안된다.
애그리거트는 경계를 갖는다.
한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
- ex) 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만, 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지는 않는다.
'A가 B를 갖는다' 로 설계할 수 있는 요구사항이 있을 때 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
- ex) 상품 상세 페이지에 들어가면 상품 상세 정보와 함께 리뷰 내용을 보여줘야 한다는 요구 사항이 있을 때 Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다. 하지만 Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다. 게다가 Product를 변경하는 주체가 상품 담당자라면 Review를 생성하고 변경하는 주체는 고객이다. 이럴 경우 서로 영향을 주지 않기 때문에 다른 애그리거트에 속한다.

애그리거트 루트

도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다.
애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 애그리거트의 루트 엔티티이다.
애그리거트 루트 엔티티는 애그리거트의 대표 엔티티로, 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.
애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.
애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
- 애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안 된다.
- 아래의 예제 코드처럼 애그리거트 루트인 Order에서 ShippingInfo를 가져와 직접 정보를 변경하는데 이는 업무 규칙을 무시하고 직접 DB 테이블의 데이터를 수정하는 것과 같은 결과를 만든다.
- 즉, 논리적인 데이터 일관성이 깨지게 되는 것이다.
- 이렇게 되면 동일한 검사 로직을 여러 응용 서비스에서 중복으로 구현할 가능성이 높아져 유지 보수에 도움이 되지 않는다.

ShippingInfo si = order.getShippingInfo();
si.setAddress( newAddress );

불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하기 위한 습관

1. 단순한 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.

공개 set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킨다.
도메인 로직이 한 곳에 응집되지 않으므로 코드를 유지 보수할 때에도 분석하고 수정하는 데 더 많은 시간이 필요하다.
도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
공개 set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다.
- ex) cancel, changePassword처럼 의미가 더 잘 드러나는 이름을 사용하는 빈도가 높아진다.

2. 밸류 타입은 불변으로 구현한다.

밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
애그리거트 외부에서 내부 상태를 함부로 바꾸지 못하므로 애그리거트의 일관성이 깨질 가능성이 줄어든다.

애그리거트 루트의 기능 구현

애그리거트 루트가 구성요소의 상태만 참조하는 것은 아니다. 기능 실행을 위임하기도 한다.

public class OrderLines {
	private List<OrderLine> lines;
    public void changeOrderLines( List<OrderLine> newLines ) {
    	this.lines = newLines;
    }
}

public class Order {
	private OrderLines orderLines;
    public void changeOrderLines( List<OrderLine> newLines ) {
    	orderLines.changeOrderLines( newLines );
        this.totalAmounts = orderLines.getTotalAmounts();
    }
}

======================================================================
OrderLines lines = order.getOrderLines();

// 외부에서 애그리거트 내부 상태 변경
// order의 totalAmounts가 값이 OrderLines가 일치하지 않게 됨
lines.changeOrderLines( newOrderLines );

OrderLines의 changeOrderLines()를 바로 접근하게 되면 총합을 계산하지 않는 버그가 발생한다.
이런 버그가 생기지 않도록 하려면 애초에 애그리거트 외부에서 OrderLine 목록을 변경할 수 없도록 OrderLines를 불변으로 구현하면 된다.
불변으로 구현할 수 없는 경우 패키지나 protected 범위로 한정해서 외부에서 실행할 수 없도록 제한하는 방법도 있다.
보통 한 애그리거트에 속하는 모델은 한 패키지에 속하기 때문에 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능을 실행하는 것을 방지할 수 있다.

트랜잭션 범위

트랜잭션 범위는 작을수록 좋다.
한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생한다.
잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고 전체적인 성능을 떨어뜨린다.
한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아지기 때문에 한 번에 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어지게 된다.
애그리거트는 최대한 서로 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.
결합도가 높아지면 높아질수록 향후 수정 비용이 증가하므로 애그리거트에서 다른 애그리거트의 상태를 변경하지 말아야 한다.
부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고 응용 서비스에서 두 애그리거트를 수정하도록 구현한다.
한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
- 팀 표준 : 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
- 기술 제약 : 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
- UI 구현의 편리 : 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

리포지터리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 리포지터리를 각각 만들지 않고 Order를 위한 리포지터리만 존재한다.
새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어야 하므로, 두 메서드를 기본으로 제공한다.
- save : 애그리거트 저장
- findById : ID로 애그리거트를 구함
이 외에도 필요에 따라 다양한 조건으로 추가할 수 있다.
어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야한다.
동일하게 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
- order 애그리거트는 orderLine, orderer 등 모든 구성 요소를 포함하고 있어야한다.
- 완전한 애그리거트를 제공하지 않으면 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 도중 NPE가 발생할 수 있다.

ID를 이용한 애그리거트 참조

애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조한다는 것과 같다.
필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다. 하지만 필드를 이용한 애그리거트 참조는 다음 문제를 야기할 수 있다.
- 편한 탐색 오용
  - 한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.
  - 쉽게 변경할 수 있기 때문에 유횩에 빠지기 쉽다.
  - 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
- 성능에 대한 고민
  - 지연( lazy ) 로딩
    - 관련된 데이터를 필요로 할 때만 가져오는 방식
      - ex) 객체의 프로퍼티 중 하나가 다른 객체와 연결되어 있을 경우, 해당 객체가 접근되기 전까지는 연결된 객체의 데이터를 가져오지 않는다. 불필요한 데이터를 로딩하지 않아 애플리케이션의 성능을 향상시킬 수 있다.
    - 애그리거트의 상태를 변경하는 기능을 실행하는 경우에는 불필요한 객체를 함께 로딩할 필요가 없으므로 지연 로딩이 유리
  - 즉시( eager ) 로딩
    - 객체를 가져올 때 관련된 모든 데이터를 한 번에 가져오는 방식
      - ex) 관련된 모든 데이터를 로딩하기 때문에 데이터베이스 쿼리를 한번에 처리할 수 있으므로 성능이 향상될 수 있지만 모든 데이터를 한 번에 가져오므로 불필요한 데이터를 가져오는 경우가 발생한다.
    - 연관된 객체의 데이터를 함께 화면에 보여줘야 하면 즉시 로딩이 조회 성능에 유리
  - 객체의 프로퍼지 중에 자주 접근되는 데이터는 즉시로딩, 드물게 접근되는 데이터는 지연로딩을 사용하여 최적의 성능을 얻을 수 있다.
- 확장 어려움
  - 사용자가 늘고 트래픽이 증가하면 자연스럽게 부하를 분산하기 위해 하위 도메인별로 시스템을 분리하기 시작한다.
  - 이 과정에서 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  - 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.
이 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다.
ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.
이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
또한, 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다.
ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.

ID를 이용한 참조와 조회 성능

조회 대상이 N개일 때 N개를 읽어오는 한 번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다. 해서 이를 N+1 조회 문제 라고 한다.
ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는 데 지연 로딩과 관련된 대표적인 문제가 N+1 조회 문제이다.
N+1 조회 문제는 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
이 문제가 발생하지 않도록 하려면 조인을 사용해야 한다.
조인을 사용하는 가장 쉬운 방법은 ID 참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 사용하도록 매핑 설정을 바꾸는 것이다.
JPQL은 애그리거트를 조인으로 조회하여 한 번의 쿼리로 로딩한다. 즉시 로딩이나 지연 로딩과 같은 로딩 전략을 고민할 필요 없이 조회 화면에서 필요한 애그리거트 데이터를 한 번의 쿼리로 로딩할 수 있다.
처음 JPA를 사용하면 각 객체 간 모든 연관을 지연 로딩과 즉시 로딩으로 어떻게든 처리하려고 하지만 ID를 이용해 애그리거트를 참조해도 한 번의 쿼리로 필요한 데이터를 로딩하는 것이 가능하다.

애그리거트 간 집합 연관

애그리거트 간 1-N 관계는 Set과 같은 컬렉션을 이용해서 표현할 수 있다.
ID 참조를 이용한 M-N 단방향 연관

@Entity
@table( name = "product" )
public class Product {
	@EmbeddedId
    private ProductId id;
    
    @ElementCollection
    @CollectionTable( name = "product_category",
    	joinColumns = @JoinColumn( name = "product_id" ))
    private Set<CategoryId> categoryIds;
}

이 매핑은 카테고리 ID 목록을 보관하기 위해 밸류 타입에 대한 컬렉션 매핑을 이용했다.
이 매핑을 사용하면 다음과 같이 JPQL의 member of 연산자를 이용해 특정 Category에 속한 Product 목록을 구하는 기능을 구현할 수 있다.

@Repository
public class JpaProductRepository implements ProductRepository {
	@PersistenceContext
    private EntityManager entityManager;
    
    @Override
    public List<Product> findByCategoryId( CategoryId catId, int page, int size ) {
    	TypedQuery<Product> query = entityManager.createQuery(
        	"select p from Product p " +
            "where :catId member of p.categoryIds order by p.id.id desc",
            Product.class
        );
        query.setParameter("catId", catId);
        query.setFirstResult((page -1) * size);
        query.setMaxREsults(size);
        return query.getResultList();
    }
}

위 코드에서 ":catId member of p.categoryIds"는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건이다.
응용 서비스는 이 기능을 사용해서 지정한 카테고리에 속한 Product 목록을 구할 수 있다.

애그리거트를 팩토리로 사용하기

public class RegisterProductService {
	public ProductId registerNewProduct( NewProductRequest req ) {
    	Store store = storeRepository.findById( req.getStoreId() );
        checkNull( store );
        
        if( store.isBlocked() ) {
        	throw new StoreBlockedException();
        }
        ProductId id = productRepository.nextId();
        Product product = new Product(id, store.getId(), ...);
        productRepository.save(product);
        return id;
    }
}

위 예제 코드는 중요한 도메인 로직 처리를 응용 서비스에서 구현하고 있는 문제가 있다.
Product를 생성하는 기능을 Store 애그리거트에 구현할 수도 있다.

public class Store {
	public Product createProduct( ProductId newProductId, ... ) {
    	if ( isBlocked() ) throw new StoreBlockedException();
        return new Product( newProductId, getId(), ... );
    }
}

public class RegisterProductService {
	public ProductId registerNewProduct( NewProductRequest req ) {
    	Store store = storeRepository.findById( req.getStoreId() );
        checkNull( store );
        ProductId id = productRepository.nextId();
        Product product = store.createProduct(id, ...);
        productRepository.save(product);
        return id;
    }
}

Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다.
팩토리 역할을 하면서도 중요한 도메인 로직을 구현하고 있다.
더 이상 Store의 상태를 확인하지 않아도 된다.
도메인 로직을 변경해도 해당 도메인 영역만 변경하면 되고 응용 서비스는 영향을 받지 않고 도메인의 응집도도 높아졌다.
이는 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점이다.
다른 팩토리에 위임하더라도 도메인 로직은 한 곳에 계속 위치한다.

'DDD' 카테고리의 다른 글

[ DDD ] 02. 아키텍처 개요 (1)	2023.04.30
[DDD] 01. 도메인 모델 시작하기 (0)	2023.04.23

현재글[ DDD ] 03. 애그리거트

솔솔의 천방지축 개발일기

[ DDD ] 03. 애그리거트

'DDD' 카테고리의 다른 글

'DDD'의 다른글

티스토리툴바

[ DDD ] 03. 애그리거트

'DDD' 카테고리의 다른 글

'DDD'의 다른글

관련글

티스토리툴바