[도메인 주도 개발 시작하기] 3. 애그리거트

 

1. 애그리거트

 

객체 상위 수준에서의 관점

 

개별 객체 단위에서의 관점

 

상위 수준에서 모델을 정리하면 도메인 모델의 복잡한 관계를 이해하는 데 도움이 된다. 개별 객체 단위로 정리하게 되면 상위 모델에 대한 이해 없이 상위 수준에서 개념을 파악하기 어려워진다. 더 많은 코드를 보고 도메인 전문가와 더 많은 대화를 나눠야 상위 수준에서 모델 간의 관계가 이해된다.

 

백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 개별 테이블 간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는 데 어려움을 겪게 되는 것처럼, 도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.

 

주요 도메인 요소 간의 관계를 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 상위 수준에서 모델이 어떻게 엮여 있는지 알아야 전체 모델을 망가뜨리지 않고 추가 요구사항을 반영할 수 있는데, 개별 모델만 이해한 상태로는 코드를 수정하는 것이 꺼려지기 때문에 코드 변경을 최대한 회피하는 쪽으로 요구사항을 협의하게 된다.

 

애그리거트

복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 바로 애그리거트이다.

 

애그리거트는 관련된 객체를 하나의 군으로 묶어 준다. 수많은 객체를 애그리거트로 묶음으로써 모델 간의 관계를 개별 모델 수준과 상위 수준에서 모두 이해할 수 있다.

 

애그리거트는 모델을 이해하는 데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 된다. 모델을 보다 잘 일해할 수 있고 애그리거트 단위로 일관성을 관리하기 때문에, 애그리거트는 복잡한 도메인을 단순한 구조로 만들어준다. 복잡도가 낮아지는 만큼 도메인 기능을 확장하고 변경하는 데 필요한 개발 시간이 줄어든다.

 

애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다. 애그리거트에 속한 구성요소는 대부분 함께 생성하고 제거한다.

 

애그리거트는 경계를 갖고, 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트는 관리하지 않는다. 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되거나, 함께 변경되는 빈도가 높은 객체는 한 애그리거트에 속할 가능성이 높다.

 

흔히 'A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽지만 반드시 한 애그리거트에 속하는 것은 아니다. 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 한 애그리거트로 묶을 수 있지만, 상품과 리뷰의 경우 상품 페이지에서 상품과 리뷰를 보여주지만 상품과 리뷰는 함께 생성되지도 않고 함께 변경되지도 않는다. 게다가 상품과 리뷰의 변경 구체는 상품 담당자와 고객으로 서로 다르다. 따라서 서로 다른 애그리거트에 속한다.

 

2. 애그리거트 루트

애그리거트는 여러 객체로 구성되기 때문에 한 객체만 상태가 정상이면 안되고, 도메인 규칙을 지키기 위해 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다.

 

예를 들어 주문 애그리거트는 다음을 포함한다고 했을 때,

• 총 금액인 totalAmounts를 갖고 있는 Order 엔티티(OrderLine 밸류를 가지고있음)
• 개별 구매 상품의 개수 quantity, 금액 price를 갖고 있는 OrderLine 밸류

구매할 상품의 개수를 변경하면 한 OrderLine의 quantity를 변경하고 더불어 Order의 totalAmounts도 변경해야 한다. 그렇지 않으면 '주문 총 금액은 개별 상품의 주문 개수 X 가격의 합' 라는 도메인 규칙을 어기고 객체들 상태의 일관성이 깨진다.

 

애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 그것이 바로 애그리거트의 루트 엔티티이다. 애그리거트 루트 엔티티는 애그리거트의 대표 엔티티이고, 애그리거트에 속한 객체는 루트 엔티티에 직/간접적으로 속한다.

 

주문 애그리거트의 루트는 Order

 

 

애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것으로 , 이를 위해 애그리거트가 제공해야 할 도메인 기능을 구현한다. 예를 들어 주문 애그리거트는 배송지 변경, 상품 변경과 같은 기능을 제공하고, 애그리거트 루트인 Order가 이 기능을 구현한 메서드를 제공한다.

 

애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애드리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다. 배송이 시작되기 전까지만 배송지 정보를 변경할 수 있다는 규칙이 있다면, 애그리거트 루트인 Order의 changeShippingInfo 메서드는 이 규칙에 따라 배송 시작 여부를 확인하고 구칙을 충족할 때만 배송지 정보를 변경해야 한다.

 

public class Order {
	// 애그리거트 루트는 도메인 규칙을 구현한 기능을 제공한다.
    public void changeShippingInfo(ShippingInfo newShippingInfo) {
    	verifyNotYetShipped();
        setShippingIngo(newShippingInfo);
    }
    
    private void verifyNotYetShippied() {
    	if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
        	throw new IllegalStateException("already shipped");
        }
    }
    
    ...
}

 

또한 애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다. 이것은 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이 된다.

 

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

 

 

위 코드는 애그리거트 루트인 Order에서 ShippingInfo를 가져와 직접 정보를 변경하는 코드이다. 주문 상태에 상관없이 배송지 주소를 변경할 수 있는데 이는 업무 규칙을 무시하고 DB 테이블에서 직접 데이터를 수정하는 것과 같은 결과를 만든다. 즉, 논리적인 데이터 일관성이 깨지게 되는 것이다.

불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들려면 도메인 모델에 대해 다음의 두 가지를 습관적으로 적용해야 한다.

• 단순한 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.
• 밸류 타입은 불변으로 구현한다.

공개 set 메서드는 중요 도메인의 의미나 의도를 표현하지 못하고 도메인 로직이 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산되게 만드는 원인이 된다. 공개 set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다.

밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 값을 변경할 수 없기 때문에 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없게 된다.

 

public class Order {
	private ShippingInfo shippingInfo;
    
    public void changeShippingInfo(Shippinginfo newShippingInfo) {
    	verifyNotYetShipped();
        setShippingInfo(newShippingInfo);
    }
    
    private void setShippingInfo(ShippingInfo new Shippinginfo) {
	// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경해야 한다.
    	// 불변이므로 this.shippingInfo.setAddress(newShippingInfo.getAddress())와 같은 코드는
    	// 사용할 수 없다.
    	this.shippingInfo = newShippingInfo;
	}
}

 

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다. 예를 들어 Order는 총 주문 금앨을 구하기 위해 OrderLine 목록을 사용한다.

 

트랜잭션

트랜잭션 범위는 작을수록 좋다. 한 트랜잭션이 하나의 테이블을 수정한는 것과 비교하면 세 개의 테이블을 수정하는 것은 잠금 대상이 더 많아진다는 의미다. 잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 뜻하고 이는 전체적인 성능을 떨어뜨린다.

동일하게 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다. 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아지기 때문에 한번에 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어지게 된다.

만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 응용 서비스에서 두 애그리거트를 수정하도록 구현해야 한다.

 

3. 리포지터리와 애그리거트

 

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. 새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어야 하므로, 리포지터리는 두 메서드를 기본으로 제공한다.

• save : 애그리거트 저장
• findById : ID로 애그리거트를 구함

 

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

 

애그리거트는 다른 애그리거트를 참조한다. 애그리거트 관리 주체는 애그리거트 루트이므로 다른 애그리거트의 루트를 참조한다는 의미이다. 애그리거트 간의 참조는 필트를 통해 쉽게 구현할 수 있다. 하지만 필드를 이용한 애그리거트 참조는 다음의 문제를 야기할 수 있다.

 

public class Order {
	private Orderer orderer;

	public void changeShippingInfo( ... ) {
		...
		// Member의 Address를 변경한다. 
		orderer.getCusotmer().changeAddress(newShippingInfo.getAddress());
	}
}

 

• 편한 탐색 오용
• 성능에 대한 고민
• 확장 어려움

 

한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다. 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.

 

두 번째 문제는 애그리거트를 직접 참조하면 성능과 관련된 여러 가지 고민을 해야 한다. JPA를 사용할 경우 참조한 객체를 지연로딩과 즉시로딩의 두 가지 방식으로 로딩할 수 있다.

 

세 번째 문제는 확장이다. 초기에는 단일 서버에 단일 DBMS로 서비스를 제공하는것이 가능하다. 문제는 사용자가 몰리기 시작하면서 하위 도메인별로 시스템을 분리하기 시작한다. 이 과정에서 하위 도메인마다 서로 다른 DBMS를 사용할 가능성이 높아진다. 이는 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.

 

이를 해결할 수 있는 방법이 ID를 이용해서 다른 애그리거트를 참조하는 것이다. ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복작도를 낮춰준다. 또한, 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다. 이는 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원척적으로 방지할 수 있다.

public class Order {
	private Orderer orderer;

	public void changeShippingInfo( ... ) {
		...
		// Member의 Address를 변경한다. 
		Member member = memberRepository.findById(order.getOrderer().getMemberId());
		member.changeAddress(newShippingInfo.getAddress());
	}
}

 

또한 애그리거트별로 다른 구현 기술을 사용하는 것도 가능해진다. 또한, 각 도메인을 별도 프로세스로 서비스하도록 구현할 수도 있다.

 

ID로 애그리거트를 참조하면 리포지터리마다 다른 저장소를 사용하도록 구현할 때 확장이 용이하다.

 

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

 

다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽어야 할 때 조회속도가 문제될 수 있다. 애그리거트마다 서로 다른 저장소를 사용하는 경우에는 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이런 경우 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다. 이 방법은 코드가 복잡해지는 단점이 있지만 시스템의 처리량을 높일 수 있다는 장점이 있다. 특히 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법이다.

 

5. 애그리거트 간 집합 연관

 

애그리거트 간 1:N과 M:N 연관에 대해 살펴보면, 이 두 연관은 컬렉션을 이용한 연관이다. 카테고리와 상품 간의 연관이 대표적이다.

• 카테고리 입장에서 한 카테고리에 한 개 이상의 상품이 속할 수 있으니 카테고리와 상품은 1:N 관계
• 상품 입장에서 한 상품이 한 카테고리에만 속할 수 있다면 상품과 카테고리는 N:1 관계이다.

 

개념적으로 존재하는 애그리거트 간의 1:N 연관을 실제 구현에 반영하는것이 요구사항을 충족하는 것과 상관없는 경우가 종종 있다. 특정 카테고리에 있는 상품 목록을 보여주는 요구사항을 구현했을 때, 실제 DBMS와 연동해서 구현하면 Category에 속한 모든 Product를 조회하게 된다. Product 개수가 수백에서 수만 개 정도로 많다면 이 코드를 실행할 때마다 실행 속도가 급격히 느려져 성능에 심각한 문제를 일으킬 것이다. 이는 1:N 연관이더라도 N:1로 연관지어 구하면 해결할 수 있다. 상품 입장에서 자신이 속한 카테고리는 N:1로 연관지어 구하면 된다.

 

M:N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다. RDBMS를 이용해서 M:N 연관을 구현하려면 조인 테이블을 이용해서 구현하면 된다.

 

 

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

고객이 특정 상점을 여러 차례 신고를 해서 해당 상점이 더 이상 물건을 등록하지 못하도록 차단한 상태라고 할 때

public class RegisterProductService {
	public ProductId registerNewProduct(NewProductRequest req) {
		Store store = storeRepository.findStoreById(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;
	}
}

위 코드처럼 작성할 수 있다. 코드가 나빠 보이지는 않지만 중요한 도메인 로직 처리가 응용 서비스에 노출되었다. Store가 Product를 생성할 수 있는지 여부를 판단하고 Product를 생성하는 것은 논리적으로 하나의 도메인 기능인데 이 도메인 기능을 응용 서비스에서 구현하고 있는 것이다. 이 기능을 Store 애그리거트에 구현할 수 있다.

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

Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다. 응용 서비스는 팩토리 기능을 이용해서 Product를 생성하면 된다.

 

Store가 Product를 생성할 수 있는지를 확인하는 도메인 로직은 Store에 구현하고 있기 때문에, Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다. 도메인의 응집도도 높아졌다. 이것이 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점이다.

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해보면 좋다.

 

 

출처 : 최범균, 『도메인 주도 개발 시작하기 DDD 핵심 개념 정리부터 구현까지』, 한빛미디어(2022), p98-p127