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

애그리거트

도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다. 

 주요 도메인 요소 간의 관계를 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 

 

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

애그리거트는 모델을 이해하는 데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 된다. 속한 구성요소는 대부분 함께 생성하고 함께 제거한다. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 

 

처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다. 

 

애그리거트 루트와 역할

도메인 규칙과 일관성

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

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

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

 

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

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

도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다. 공개 set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다. 

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

보통 한 애그리거트에 속하는 모델은 한 패키지에 속하기 때문에 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능을 실행하는 것을 방지할 수 있다. 

 

트랜잭션 범위

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

public class ChangeOrderService{
	//두 개 이상의 애그리거트를 변경해야 하면,
    //응용 서비스에서 각 애그리거트의 상태를 변경한다. 
    @Transactional
    public void changeShippingInfo(OrderId id, ShippingInfo newShippingInfo,
    							boolean useNewShippingAddrAsMemberAddr){
    	Order order = orderRepository.findbyId(id);
        if(order == null) throw new OrderNotFoundException();
        order.shipTo(newShippingInfo);
        if(useNewShippingAddrAsMemberAddr){
       		Member member = findMember(order.getOrderer());
            member.changeAddress(newShippingInfo.getAddress());
        }
    }
    ...

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

 

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

 

애그리거트와 리포지터리

새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어야 하므로, 리포지터리는 보통 다음의 두 메서드를 기본으로 제공한다. 

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

//리포지터리에 애그리거트를 저장하면 애그리거트 전체를 영속화해야 한다. 
orderRepository.save(order);

//리포지터리는 완전한 order를 제공해야 한다. 
Order order = orderRepository.findById(orderId);

//order가 온전한 애그리거트가 아니면
//기능 실행 도중 NullPointerException과 같은 문제가 발생한다. 
order.cancel();

애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 

 

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

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

 

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

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

public class Order{
	private Orderer orderer;
    
    public void changeShippingInfo(ShippingINfo newShippingInfo,
    							boolean useNewShippingAddrAsMemberAddr){
    	...
        if(useNewShippingAddrAsMemberAddr){
        	//한 애그리거트 내부에서 다른 애그리거트에 접근할 수 있으면, 
            //구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 
            //유혹에 빠지기 쉽다. 
            order.getMember().changeAddress(newShippingInfo.getAddress());
        }
    }
}

한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다. 

단순히 연관된 객체의 데이터를 함께 화면에 보여줘야 하면 즉시 로딩이 조회 성능에 유리하지만 애그리거트의 상태를 변경하는 기능을 실행하는 경우에는 불필요한 객체를 함께 로딩할 필요가 없으므로 지연 로딩에 유리할 수 있다. 이런 다양한 경우의 수를 고려해서 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다. 

하위 도메인마다 다른 종류의 데이터 저장소를 사용하기도 한다. 이것은 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다. 

 

ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용한다. 

 

애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다. 구현 복잡도도 낮아진다. 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다. 

 

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

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

Member member = memberRepository.findById(ordererId);
List<Order> orders = orderRepository.findByOrderer(ordererId);
List<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 조회 문제가 발생. 전체 조회 속도가 느려지는 원인이 된다. 조인을 사용해야 한다. ID 참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 사용하도록 매핑 설정을 바꾸는 것이다. ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다. 

 

@Repository
public class JpaOrderViewDao implements OrderViewDao {
    @Override
    public List<OrderView> selectByOrderer(String ordererId) {
        String selectQuery = 
        "select .....
        join ....";
    }
}

쿼리가 복잡하거나 SQL에 특화된 기능을 사용해야 한다면 조회를 위한 부분만 마이바티스와 같은 기술을 이용해서 구현할 수도 있다.

 

애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이때는 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다. 이 방법은 코드가 복잡해지는 단점이 있지만 시스템의 처리량을 높일 수 있다는 장점이 있다. 

 

애그리거트 간 집합 연관

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;
}

@Repository
public class JpaProductRepository implements ProductRepository {
    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public List<Product> findByCategoryId(CategoryId categoryid, 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", categoryId);
        query.setFirstResult((page - 1) * size);
        query.setMaxResults(size);
        return query.getResultList();
    }
}