3장 : 애그리거트

애그리거트

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

애그리거트는 애그리거트 단위로 일관성을 관리하기 때문에, 복잡한 도메인을 단순한 구조로 만들어준다. 이는 도메인 기능을 확장하고 변경하는 데 필요한 시간도 줄어든다.

경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.

'A가 B를 갖는다'로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.

example

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

Reiview의 변경이 Prduct에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 때문에 이 둘은 한 애그리거트에 속하기 보다는 서로 다른 애그리거트에 속한다.

애그리거트 루트

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

도메인 규칙과 일관성

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

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

밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능하다. 그러므로 애그리거트 루트가 도메인 규칙을 올바르게만 구현하면 애그리거트 전체의 일관성을 올바르게 유지할 수 있다.

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

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다. 애그리거트는 구성요소의 상태를 참조하고 기능 실행을 위임한다.

public class Member {
    private Password password;
    
    public void changePassword(String currentPassword, String newPassword) {
        if (!password.match(currentPassword)) {
            thorw new PasswordNotMatchException();
        }
        this.password = new Password(newPassword);
    }
}

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

트랜잭션 범위

트랜잭션 범위는 작을수록 좋다. 한 개 테이블을 수정하면 트랜잭션 충돌을 막기 위해 잠그는 대상이 한 개 테이블의 한 행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 많아진다. 잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고 이것은 전체적인 성능(처리량)을 떨어뜨린다.

동일하게 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다. 결합도가 높아지면 높아질수록 향후 수정 비용이 증가하므로 애그리거트에서 다른 애그리거트의 상태를 변경하지 말아야 한다.

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

public class ChangeOrderService {
    
    @Transactional
    public void changeShippingInfo(OrderId id, ShippingInfo newShippingInfo, 
            boolean useNewShippingAddrAsMemberAddr) {
        Order order = orderRepository.findbyId(id);
        if (order == null) throw new OrderNotException();
        order.shipTo(newShippingInfo);
        if (useNewshippingAddrAsMemberAddr) {
            Member member = findMember(order.getOrderer());
            member.changeAddress(newShippingInfo.getAddress());
        }
    }
    ...
}

도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서도 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.

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

팀 표준 - 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
기술 제약 - 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
UI 구현의 편리 - 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

리포지터리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. 즉, 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.

example

Order와 OrderLine을 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrderLine을 위한 리포지터리를 각각 만들지 않는다.

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

리포지터리는 보통 다음의 두 메서드를 기본으로 제공한다.

save - 애그리거트 정장
findById - ID로 애그리거트르 구함

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

애그리거트는 다른 애그리거트를 참조할 수 있는데, 이때 참조는 필드를 통해 구현할 수 있다.

JPA는 @ManyToOne, @OneToOne과 같은 애너테이션을 이용해서 연관된 객체를 로딩하는 기능을 제공하고 있으므로 필드를 이용해 다른 애그리거트를 쉽게 참조할 수 있다.

order.getOrder().getMember().getId()

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

편한 탐색 오용 - 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
성능에 대한 고민 - 단순히 연관된 객체의 데이터를 함께 화면에 보여줘야 하면 즉시 로딩이 조회 성능에 유리하지만 애그리거트의 상태를 변경하는 기능을 실행하는 경우에는 지연 로딩이 유리할 수 있다.
확장 어려움 - 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.

이런 세 가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다. 응용 서비스에서 필요한 애그리거트를 로딩하므로 애그리거트 수준에서 지연 로딩을 하느 것과 동일한 결과를 만든다.

public class ChangeOrderService {
    
    @Transactional
    public void changeChippingInfo(OrderId id, ShippingInfo newShippingInfo,
            boolean userNewShippingAddrAsMemberAddr) {
        Order order = orderRepository.findbyId(id);
        if (order == null) throw new OrderNotFoundException();
        order.chagneShippingInfo(newShippingInfo);
        if (useNewshippingAddrAsMemberAddr) {
            Member member = memberRepository.findById(
                order.getOrderer().getMemberId());
            member.changeAddress(newShippingInfo.getAddress());
        }
    }
    ...
}

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

ID를 이용한 참조와 조회 성

iuiuiu 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다. 한 DBMS에 데이터가 있다면 조인을 이용해서 한 번에 모든 데이터를 가져올 수 있음에도 불구하고 주문마다 상품 정보를 읽어오는 쿼리를 실행하게 된다.

Member member = memberRepository.findBy(ordererId);
List<Order> orders = orderRepository.findByOrderer(orderId);
Lisr<OrderView> dtos = orders.stream()
        .map(order -> {
                ProductId prodId = order.getOrderLines().get(0).getProductId();
                Product product = productRepository.findById(prodId);
                return new OrderView(order, member, product);
        }).collect(toList());

N + 1 조회 문제

조회 대상이 N개일 때 N개를 읽어오는 한 번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다
더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.

ID 참조 방식을 사용하면서 N + 1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다. (아래 예시는 JPQL 사용)

@Repository
public class JpaOrderViewDao implements OrderViewDao {
    
    @PersistenceContext
    private EntityManager em;
    
    @Override
    public List<OrderView> selectByOrderer(String orderId) {
        String selectQuery = 
            "select new com.myshop.order.application.dto.OrderView(o, m, p)" + 
            "from Order o join o.orderLines ol, Member m, Product p" +
            "where o.orderer.memberId.id = :ordererId" +
            "and o.orderer.memberId = m.id" +
            "and index(ol) = 0 " +
            "and ol.productId = p.id " +
            "order by o.number.number desc";
        TypeQuery<OrderView> query = 
            em.createQuery(selectQuery, OrderView.class);
        query.setParameter("ordererId", ordererId);
        return query.getResultList();
    }
}

ㅇgdfgdfg 처음 JPA를 사용하면 각 객체 간 모든 연관을 지연 로딩과 즉시 로딩으로 어떻게든

처리하고 싶은 욕구에 사로잡힌다. 하지만 이것은 실용적이지 않다. --> ???????

애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이때는 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다. 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법이다.

애그리거트 간 집합 연관

1-N

애그리거트 간 1-N 관계는 Set과 같은 컬렉션을 이용해서 표현할 수 있다.

public class Category {
    
    private Set<Product> products; // 다른 애그리거트에 대한 1-N 연관
}

그런데 개념적으로 존재하는 애그리거트 간의 1-N 연관을 실제 구현에 반영하는 것이 요구사항을 충족하는 것과는 상관없을 때가 있다.

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

특정 카테고리에 속한 상품 목록을 보여주는 요구사항의 경우 상품 입장에서 자신이 속한 카테고리를 N-1로 연관지어 구한다.

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

카테고리에 속한 상품 목룍을 제공하는 응용 서비스는 ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Product 목록을 구한다.

public class ProductListservice {
    
    public Page<Product> getProductOfCatedory(Long categoryId, int page, int size) {
        Category category = categoryRepository.findById(categoryId);
        checkCategory(category);
        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 연관이 존재하지만 실제 구현에서는 상품에서 카테고리의 단방향 M-N 연관만 적용하면 된다.

public class Product {

    private Set<CategoryId> categoryIds;
    ...
}

RDBMS에서 M-N 연관을 구현하려면 조인 테이블을 사용한다.

JPA를 이용하면 다음과 같은 매핑 설정을 사용해서 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.setMaxResult(size);
        return query.getResultList();
    }
    ...
}

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

상점 계정이 차단 상태가 아닌 경우에만 상품을 생성하도록 구현해보자.

public class RegisterProductService {

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

코드가 나빠 보이지는 않지만 중요한 도메인 로직 처리가 응용 서비스에 노출되었다.

이 도메인 기능을 넣기 위한 별도의 도메인 서비스나 팩토리 클래스를 만들 수도 있지만 Store 애그리거트에 구현할 수도 있다.

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

Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 하면서도 중요한 도메인 로직을 구현하고 있다. 팩토리 기능을 구현했으므로 이제 응용 서비스는 팩토리 기능을 이용해서 Product를 생성하면 된다.

public class RegisterProductService {

    public ProductId registerNewProduct(NewProductRequest req) {
        Store store = storeRepository.findById(req.getStoreId());
        ProductId id = productRepository.nextId();
        Product product = new Product(id, store.getId(), ... 생략);
        productRepository.save(product);
        return id;
    }
    ...
}

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

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

example

Product의 경우 제품을 생성한 Store의 식별자를 필요로 한다. 즉 Store의 데이터를 이용해서 Product를 생성한다. 게다가 Product를 생성할 수 있는 조건을 판단할 때 Store의 상태를 이용한다. 따라서 Store에 Product를 생성하는 팩토리 메서드를 추가하면 Product를 생성할 때 필요한 데이터의 일부를 직접 제공하면서 동시에 중요한 로직을 함께 구현할 수 있게 된다.

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

public class Store {

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

Previous2장 : 아키텍처 Next4장 : 리포지터리와 모델 구현

Last updated 1 year ago