03.애그리거트

도메인 주도 개발 시작하기 3장을 요약한 내용입니다.

애그리거트

개별 객체 수준에서 모델을 바라보면 상위 수준에서 관계를 파악하기 어렵다. 하지만, 상위 수준에서 모델을 정리하면 도메인 모델의 복잡한 관계를 이해하는 데 도움이 된다.

애그리거트는 관련된 객체를 하나의 군으로 묶어 준다. 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.

애그리거트는 복잡한 모델을 관리하는 기준을 제공.

한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.

애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.

상품이 리뷰를 갖는 것으로 생각할 수 있지만, 상품과 리뷰는 함께 생성되거나 변경되지 않고, 변경 주체도 다르기 때문에 서로 다른 애그리거트에 속한다.

애그리거트 루트

애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요하다.

이 책임을 지는 것이 바로 애그리거트의 루트 엔티티이다.

• 주문 애그리거트에서 루트 역할을 하는 엔티티는 Order.

• 주문 애그리거트에 속한 모델은 Order에 직/간접적으로 속한다.

도메인 규칙과 일관성

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

• 애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안 된다.

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

• 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않기

  • 대신 의미가 드러나는 메서드를 사용해서 구현하자(ex. cancel, changePassword)

• 밸류 타입은 불변으로 구현하기

  • 밸류 객체의 값을 변경하려면 새로운 밸류 객체를 할당하자

  • 불변으로 구현할 수 없다면, 밸류의 변경 기능을 package/protected 범위로 한정해서 외부 실행 불가하도록 제한하자

트랜잭션 범위

트랜잭션 범위는 작을수록 좋다.

동일하게 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.

• 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌 발생 가능성이 더 높이진다.

• 때문에 한 번에 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어지게 된다.

애그리거트는 최대한 서로 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

• 결합도가 높아질수록 향후 수정 비용이 증가하므로 애그리거트에서 다른 애그리거트 상태를 변경하지 말자

만일 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트 수정이 필요하다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고, 응용 서비스에서 두 애그리거트를 수정하도록 구현하자.

public class ChangeOrderService {

    @Transactional
    public void changeShippingInfo(...) {
        Order order = orderRepository.findById(id);
        order.shipTo(newShippingInfo);

        ..
        Member member = findMember(order.getOrderer());
        member.changeAddress(newShippingInfo.getAddress());
        ...
    }
}

다음의 경우 한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 것을 고려

• 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우

• 기술 제약: 기줄적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리

• UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 경우

리포지터리와 애그리거트

리포지터리는 애그리거트 단위로 존재

리포지터리에 애그리거트를 저장하면 애그리거트 전체를 영속화해야 한다.

• 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장해야 한다.

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

// 애그리거트 전체를 영속화
orderRepository.save(order);

...

// 리포지터리는 완전한 order 제공
Order order = orderRepository.findById(orderId);
// 그렇지 않다면 기능 실행 도중 NPE와 같은 문제 발생
order.cancel()

데이터의 일관성을 깨지 않으려면 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다.

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

public class Order {
    private Orderer ordere;
    ...
}

public class Orderer {
    private Member member;
    ...
}

public class Member {
  ...
}

order.getOrderer().getMember().getId();

orderer.getMember().changeAddress(newShippingInfo.getAddress());

필드를 이용한 애그리거트 참조는 다음 문제를 야기할 수 있다.

• 편한 탐색 오용

  • 다른 애그리거트를 수정하고자 하는 유혹

• 성능에 대한 고민

  • JPA를 이용하면 참조한 객체를 지연(lazy) 로딩과 즉시(eager) 로딩 중 고민

  • 연관 객체 데이터를 함께 보여줘야 한다면 즉시 로딩이 유리

  • 애그리거트 상태 변경 기능을 싱핼할 경우 불필요한 객체 로딩을 막기 위한 지연 로딩이 유리

• 확장 어려움

  • 도메인마다 서로 다른 DBMS를 사용할 경우

이 문제들은 ID를 이용해서 다른 애그리거트를 참조하면 해결할 수 있다.

• ID 참조를 사용하면 모든 객체가 참조로 연결되는 것이 아닌 한 애그리거트에 속한 객체들로만 참조로 연결

• 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하므로 모델의 복잡도를 낮춰준다.

• 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다.

• 구현 복잡도가 낮아진다.

• 다른 애그리거트를 직접 참조하지 않으므로 애그리거트 간 참조를 지연/즉시 로딩 중에 고민을 하지 않아도 된다.

public class Order {
    private Orderer ordere;
    ...
}

public class Orderer {
    private MemberId memberId;
    ...
}

public class Member {
  private MemberId id;
  ...
}

Member member = memberRepository.findById(order.getOrderer().getMemberId());
member.changeAddress(newShippingInfo.getAddress());

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

• 주문 애그리거트와 같은 중요한 데이터는 RDBMS에 저장

• 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장

• 각 도메인을 별도 프로세스로 서비스하도록 구현 가능

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

다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도 문제가 발생할 수 있다.

• 조인을 이용해서 한 번에 모든 데이터를 가져올 수 있음에도 주문마다 상품 정보를 읽어오는 쿼리를 실행하게 된다.

ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는 데 지연 로딩과 관련된 대표적인 문제가 N+1 조회 문제이다.

• 조회 대상이 N개일 때 N개를 읽어오는 한 번(1)의 쿼리와 연관된 데이터(N)를 읽어오는 쿼리를 N번 실행

ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하자.

• 데이터 조회를 위한 별도 DAO를 만돌고, DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩

• 즉시 로딩이나 지연 로딩과 같은 로딩 전략을 고민할 필요없이 한 번의 쿼리로 로딩 가능

한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

• 코드가 복잡해질 수 있지만 시스템의 처리량을 높일 수 있는 장점이 있다.

애그리거트 간 집합 연관

애그리거트 간 1-N 관계는 Set과 같은 컬렉션을 이용해서 표현 가능

public class Category {
    // 다른 애그리거트에 대한 1-N 연관(성능에 심각한 문제)
    private Set<Product> products; 
    ...

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

하지만, 카테고리에 속한 모든 상품을 조회하려면, 상품 개수가 수만 개 정도로 많을 경우 실행 속도가 급혁히 느려져 성능에 심각한 문제를 일으킬 수 있다.

• 개념적으로 애그리거트 간 1-N 연관이 있더라도 이러한 성능 문제로 애그리거트 간의 1-N 연관을 실제 구현에 반영하지 않는다.

카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카테고리를 N-1로 연관 지어 구하자.

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

...

public class ProductListService {
	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
		Category category = categoryRepository.findById(categoryId);
		checkCategory(category);
    // categoryId가 지정한 카테고리 식별자인 Product 목록 조회
		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
		int totalCount = productRepository.countsByCategoryId(category.getId());
		return new Page(page, size, totalCount, products);
	}
}

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

• 하지만, 상품이 속한 모든 카테고리가 필요한 화면은 상품 상세 화면이다.

• 개념적으로는 상품과 카테고리의 양방향 M-N 연관이 존재하지만, 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.

public class Product {
    private Set<CategoryId> categoryIds;
    ...
}

JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단방향 연관 구현이 가능하다.

• JPQL member of 연산자를 이용해서 특정 카테고리에 속한 상품 목록을 구하는 기능 구현이 가능

@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; // 밸류 타입에 대한 컬렉션 매핑
  ...
}

...

TypedQuery<Product> query = entityManager.createQuery(
      "select p from Product p "+
      // categoryIds 컬렉션에 catId로 지정한 값이 존재하는지 검사
      "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();

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

중요한 도메인 로직 처리가 응용 서비스에 노출되어 있는 경우를 보자.

public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store store = storeRepository.findStoreById(req.getStoreId());
        checkNull(store);
        // Product 생성 가능 판단
        if (!store.isBlocked()) {
            throw new StoreBlockedException();
        }
        // Product 생성
        ProductId id = productRepository.nextId();
        Product product = new Product(id, store.getId(), ...);
        productRepository.save(product);
        return id;
    }
}

해당 기능을 Store 애그리거트에 구현할 수도 있다.

• createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다.

• 팩토리 역할을 하면서도 중요한 도메인 로직을 구현하고 있다.

• 이제 응용 서비스는 팩토리 기능을 이용해서 Product를 생성하면 된다.

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.findStoreById(req.getStoreId());
        checkNull(store);
        ProductId id = productRepository.nextId();
        Product product = store.createProduct(id, store.getId(), ...);
        productRepository.save(product);
        return id;
    }
}

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

• 응용 서비스에서 더 이상 Store 상태를 확인하지 않아도 된다.

• Product 생성 가능 여부 확인을 위한 도메인 로직이 변경되어도 응용 서비스는 영향을 받지 않는다.

• 도메인의 응집도가 높아졌다.

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

Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면, Store 애그리거트에서 Product 애그리거트를 직접 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.

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