[DDD START!] Chap3. 애그리거트

애그리거트

상위 수준 개념을 이용해서 전체 모델을 정리하면 복잡한 모델의 전반적인 관계를 이해하는 데 도움이 된다.

주요 도메인 개념 간의 관계를 파악하기 어렵다는 건 코드를 변경하고 확장하는 게 어려워진다는 걸 의미한다.

상위 수준에서 모델이 어떻게 엮어 있는지 알아야 전체 모델을 망가뜨리지 않으면서 추가 요구사항을 모델에 반영할 수 있다.

 

따라서 복잡한 도메인을 관리하기 쉬운 단위로 만들려면 애그리거트를 이용할 수 있다.

애그리거트는 일관성을 관리하는 기준이 되기도 한다.

관련된 모델을 하나로 묶은 것이기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 가진다.

애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다. (도메인 규칙에 따라 간혹 다르기도 함)

 

또한 위 그림처럼 애그리거트는 경계를 가진다. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 애그리거트는 독립된 객체 군이며, 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다. 예를 들어, 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.

 

이러한 경계를 설정할 때 기본이 되는 건 도메인 규칙과 요구사항이다.

도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.

 

이때 주의해야할 점은 'A를 B를 갖는다' 라는 설계 요구사항이다.

해당 요구사항이 있다고 해서 무조건 A, B를 한 애그리거트라고 생각해서는 안된다.

예를 들어, '상품은 리뷰를 가진다' 라는 요구사항이 있다고 해서 두 객체의 라이프사이클이 같지 않다. 따라서 다른 애그리거트이다.

 

도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 실제 애그리거트의 크기는 줄어들게 된다.

실제로는 다수의 애그리거트가 한 개의 엔티티 객체만 가지는 경우가 많으며, 두 개 이상의 엔티티로 구성되는 애그리거트는 드물다.

애그리거트 루트

애그리거트는 여러 객체로 구성되기 때문에 한 객체만 상태가 정상이어서는 안된다.

도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다.

그러기 위해서는 애그리거트 전체를 관리하는 주체가 필요한데 이것이 애그리거트 루트 엔티티이다.

애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.

도메인 규칙과 일관성

애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.

이를 위해 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다. 이 때 애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다.

public class Order {
	public void changeShippingInfo(ShippingInfo newShippingInfo) {
          verifyNotYesShipped();
          setShippingInfo(newShippingInfo);
	}
    
    private void verifyNotYesShipped() {
		...
	}
}

애그리거트 루트가 아닌 다른 객체가 애그리거트에 속한 객체를 직접 변경해서는 안된다.

그렇게 되면 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이 된다.

ShippingInfo si = order.getShippingInfo();
si.setAddress(newAddress); // 직접 변경

위 코드처럼 정보를 직접 변경하게 되면, 주문 상태에 관계 없이 배송지 주소를 바꿀 수 있다. (도메인 규칙이 깨진다)

 

이러한 점을 해결하기 위해서 응용 서비스에서 일일이 상태를 확인하는 로직을 넣을 수도 있다.

하지만 동일한 검사 로직을 여러 응용 서비스에서 중복해서 구현하게 된다.

 

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

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

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

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다.

public Class Order {
    private Money totalAmounts;
    private List<OrderLine> orderLines;
    
    private void calculateTotalAmounts() {
      int sum = orderLines.stream()
        .mapToInt(ol -> ol.getPrice() * ol.quantity())
        .sum();
      this.totalAmounts = new Money(sum);
    }
}

위 코드에서는 총 주문 금액(totalAmounts)을 구하기 위해 orderLines 목록을 사용한다.

 

애그리거트 루트는 기능 실행 자체를 위임하기도 한다.

아래 코드는 OrderLine 목록을 별도 클래스로 분리했다.

public class OrderLines {
    private List<OrderLine> lines; // 불변으로 구현해야 한다.
    
    public int getTotalAmounts() {...}
    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();
    }
}

Order의 changeOrderLines() 메서드는 내부의 orderLines 필드에 상태 변경을 위임하는 방식으로 기능을 구현했다.

 

OrderLines lines = order.getOrderLines();

lines.changeOrderLines(newOrderLines);

이때 위 코드처럼 애그리거트 외부에서 OrderLine 목록을 변경하게 된다면, totalAmounts 값이 바뀌지 않는 버그가 생긴다.

따라서 애초에 애그리거트 외부에서 OrderLine 목록을 변경할 수 없도록 OrderLines를 불변으로 구현하면 된다.

참고: 일급 컬렉션의 소개와 써야할 이유 (https://jojoldu.tistory.com/412)

트랜잭션 범위

트랜잭션 범위는 작을수록 좋다. 하나의 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 건 성능에서 차이가 발생한다. 트랜잭션이 수행될 때 트랜잭션 충돌을 막기 위해 잠그는 대상이 많아지기 때문에 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다. 이는 전체적인 성능을 떨어뜨린다.

 

마찬가지로 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.

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

 

이를 위해서는 특정 애그리거트에서 다른 애그리거트를 변경하지 않는다는 걸 의미한다.

그렇지 않으면 결과적으로 한 트랜잭션에서 두 개의 애그리거트를 수정하게 된다.

또한 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다. 애그리거트는 최대한 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아지게 된다.

 

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

리포지터리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. 물리적으로 별도의 DB 테이블에 저장한다고 해서 각각을 위한 리포지터리를 만들지 않는다. (ex. Order, OrderLine)

 

애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.

orderRepository.save(order);
// 애그리거트에 속한 모든 구성요소를 위한 테이블에 데이터를 저장해야 한다.

또한 동일하게 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.

Order order = orderRepository.findById(orderId);
// OrderLine, Orderer 등 모든 구성요소를 포함하고 있어야 한다.

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

애그리거트도 다른 애그리거트를 참조할 수 있다. 이때 애그리거트의 관리 주체는 애그리거트 루트이므로, 애그리거트가 다른 애그리거트를 참조한다는 건 애그리거트의 루트를 참조한다는 말과 동일하다.

 

가장 쉬운 방법으로는 필드를 통해 구현할 수 있다. ORM 기술을 통해 애그리거트 루트에 대한 참조를 쉽게 구현할 수 있고, 필드를 이용한 애그리거트 참조를 사용하면 다른 애그리거트의 데이터를 객체 탐색을 통해 조회할 수 있다.

 

하지만 다음과 같은 문제를 야기할 수도 있다.

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

이 중 가장 큰 문제는 편리함을 오용할 수 있다는 점이다.

한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

이럴 경우 구현의 편리함이라는 달콤함에 이끌려 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.

orderer.getCustomer().changeAddress(newShippingInfo.getAddress());
// 주문 애그리거트에서 회원 애그리거트를 수정하고 있다.

 

두 번째 문제는 애그리거트를 직접 참조하면 성능과 관련된 여러 가지 고민을 해야 한다는 점이다.

예를 들어 JPA를 사용할 경우 참조한 객체를 즉시 로딩과 지연 로딩으로 로딩할 수 있다. 이때 애그리거트의 어떤 기능을 사용하냐에 따라 두 로딩 방식 중 하나를 선택해야 한다.

 

세 번째 문제는 확장이다.

사용자가 몰리기 시작하면 단일 DBMS로 서비스를 제공하는 게 힘들어질 수 있다. 따라서 부하를 분산하기 위해 하위 도메인 별로 시스템을 분리하며 서로 다른 DBMS를 사용할 가능성이 높아진다. 이럴 경우 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 더 이상 사용할 수 없게 된다.

 

이러한 문제들을 해결하기 위한 방법으로 ID를 이용한 다른 애그리거트 참조를 활용할 수 있다.

 

ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.

덕분에 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡성을 낮춰준다.

 

또한 구현의 복잡도도 낮아진다. 애그리거트 간 참조를 즉시 로딩과 지연 로딩 중 어떤 방식으로 할지 고민하지 않아도 된다.

참조하는 애그리거트가 필요하다면 응용 서비스에서 아이디를 이용해서 로딩하면 된다.

public class ChangeOrderService {
  @Transactional
  public void changeShippingInfo(...) {
    ...
    Customer customer = customerRepository.findById(order.getgetOrderer().getCustomerId());
    ...
  }
}

응용 서비스에서 애그리거트를 로딩하기 때문에 결국 애그리거트 수준에서 지연 로딩을 하는 것과 동일한 결과를 만든다.

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

ID 참조는 참조하는 여러 애그리거트를 함께 조회해야 할 때 성능에 이슈가 있을 수 있다. (N+1 문제)

따라서 이런 경우는 별도의 조회 전용 쿼리를 작성하는 게 적절하다.

애그리거트 간 집합 연관

애그리거트 간 1:N, M:N 연관을 정의할 때는 주로 컬렉션을 이용한다.

 

이때 개념적으로 존재하는 1:N 연관을 구현하는 게 요구사항과 상관 없는 경우가 종종 있다.

예를 들어 특정 카테고리에 있는 상품 목록을 보여주는 요구사항이 있다면 다음과 같이 구현할 수 있다.

public class Category {
  private Set<Product> products;

  public List<Product> getProducts(int page, int sze) {
    List<Product> sortedProducts = sortById(products);
    return sortedProducts.subList((page - 1) * size, page * size);
  }
}

위 코드를 실행하면 해당 카테고리에 속한 모든 상품을 조회하게 된다.

만약 상품의 개수가 엄청 많다면 실행 속도가 급격히 느려져 성능에 심각한 문제를 일으킬 수 있다.

따라서 애그리거트 간에 1:N 연관이 있더라도 이런 성능상의 문제 때문에 실제 구현에 반영하는 경우는 드물다.

 

이 같은 요구사항이 있다면 상품 입장에서 자신이 속한 카테고리를 N:1로 연관지어 구하면 된다.

public class Product {
  private CategoryId category;
  ...
}

public class ProductListService {

  public Page<Product> getProductOfCategory(...) {
    ...
    List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
    ...
  }
}

 

M:N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만들 수 있다.

이때 마찬가지로 실제 요구사항을 고려해서 M:N 연관을 구현에 포함시킬지 결정해야 한다.

 

예를 들어 특정 카테고리에 속한 상품 목록을 보여줄 때 목록 화면에서 각 상품이 속한 모든 카테고리를 표시하지는 않는다.

제품이 속한 모든 카테고리가 필요한 화면은 상품 상세 화면이다.

따라서 카테고리에서 상품으로의 집합 연관은 필요하지 않다는 걸 알 수 있다. 상품에서 카테고리로의 집합 연관만 존재하면 된다.

public class Product {
  private Set<CategoryId> categoryIds; // 밸류 타입에 대한 컬렉션 매핑
  ...
}

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

애그리거트가 가지고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현할 수 있다.

 

예를 들어 상점 계정이 차단 상태가 아닌 경우에만 새 상품을 생성할 수 있도록 구현한 코드는 다음과 같다.

public class Store extends Member {

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

이렇게 Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다.

또한 Product를 생성할 때 필요한 데이터의 일부를 제공하면서 동시에 중요한 도메인 로직을 함께 구현할 수 있게 되었다.

 

만약 응용 서비스에서 일일이 차단 여부를 확인하는 로직을 작성했다면, 중요 도메인 로직 처리가 응용 서비스에 노출된다.

이는 논리적으로 하나인 도메인 기능을 응용 서비스에서 구현하고 있는 꼴이 된다.