3장 애그리거트

3.1 애그리거트

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

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

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

애그리거트는 모델을 이해하는 데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 된다.

애그리거트를 사용하면 복잡한 도메인을 단순한 구조로 만들어주는데 이는 도메인 기능을 확장하고 변경하는데 필요한 노력(개발 시간)을 줄여준다.

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

• 주문 애그리거트를 만드려면 Order , Orderline ,Orderer 와 같은 관련된 객체를 함께 생성해야한다.
• 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성되고 함께 제거된다.

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

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

• 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다
• 함께 변경되는 빈도가 높은 객체는 한 애그리거트에 속할 가능성이 높다
• 상품 정보와 리뷰처럼 두 엔티티가 같은 애그리거트에 속한다고 생각할 수 있으나 함께 생성되지도 ,함께 변경되지도 않는다. ← 같은 애그리거트에 속하지 않는다는 말이다.

필자의 경험에 비추어 보면 다수의 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개 이상의 엔티티로 구성되는 애그리거트는 드물었다

 

 

3.2 애그리거트 루트

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

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

3.2.1 도메인 규칙과 일관성

애그리거트 루트가 단순히 애그리거트에 속한 객체를 포함하는 것으로 끝나는 것은 아니다. 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다. → 이를 위해 애그리거트 루트는 애그리거트가 제공해야할 도메인 기능을 구현한다.

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

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

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

• 이 코드는 주문 상태와 상관없이 배송지 주소를 변경하는데, 이는 업무 규칙을 무시하고 직접 DB 테이블의 데이터를 수정하는 것과 같은 결과를 만든다. ← 논리적인 데이터 일관성이 깨진다.
• 상태 확인 로직을 응용 서비스에 구현할 수도 있지만 동일한 검사 로직을 여러 응용 서비스에서 중복으로 구현할 가능성이 높아져 유지 보수에 도움이 되지 않는다.

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

• 단순히 필드를 변경하는 set메서드를 공개(public) 범위로 만들지 않는다
  • 공개 set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다.
• 밸류 타입은 불변으로 구현한다
  • 밸류 객체를 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능하다.

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

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

public class Member {
   private Password password;

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

• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인한다.

애그리거트 루트가 구성요소의 상태만 참조하는 것이 아니라 기능 실행을 위임하기도 한다.

public class Order{
   private OrderLines orderLines;

   public void changeOrderLines(List<OrderLine> newLines){
       orderLines.changeOrderLines(newLines);
       this.totalAmounts = orderLines.getTotalAmounts();
   }

• Order의 changeOrderLines() 메서드는 내부의 orderLines 필드에 상태 변경을 위임하고 있다.

3.2.3 트랜잭션 범위

트랜잭션 범위는 작을수록 좋다. 범위가 클수록 수정할 때 잠금대상이 많아진다는 의미이고 그만큼 동시에 처리할 수 있는 트랜잭션의 개수가 줄어든다 . → 전체적인 성능(처리량)을 떨어트린다.

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

한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 의미한다.

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

 

 

3.3 리포지토리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지토리는 애그리거트 단위로 존재한다.

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

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

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

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

• 리포지토리가 완전한 애그리거트를 제공하지 않으면 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 도중에 NullPointerException이 발생할 수 있다.

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

• RDBMS를 이용해서 리포지토리를 구현하면 트랜잭션을 이용해서 애그리거트의 변경이 저장소에 반영되는 것을 보장할 수 있다.
• 몽고DB를 사용하면 한 개 애그리거트를 한 개 문서에 저장함으로써 한 애그리거트의 변경을 손실 없이 저장소에 반영할 수 있다.

 

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

한 객체가 다른 객체를 참조하는 것처럼 애그리거트도 다른 애그리거트를 참조한다. ← 애그리거트의 관리 주체는 루트이므로 루트끼리 참조한다는 뜻이다.

• 애그리거트 간의 참조는 필드를 통해 쉽게 구현될 수 있다.

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

• 편한 탐색 오용
  • 다른 애그리거트를 수정할 가능성이 높아짐 ← 이러면 의존 결합도가 높아져서 애그리거트 변경이 어려워짐
• 성능에 대한 고민
• 확장 어려움
  • 사용자가 늘고 트래픽이 증가하면 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있는데 이렇다면 JPA와 같은 단일 기술을 사용할 수 없다

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

• 구현복잡도가 낮아진다.
• 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과가 있다.
• 한 애그리거트가 다른 애그리거트를 수정하는 문제를 근원적으로 막을 수 있다.
• 애그리거트 별로 다른 구현 기술을 사용하는 것도 가능해진다.

 

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

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

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

• 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
• 이 문제를 해결하기 위해 조인을 사용해야한다. ← 이는 객체 참조 방식으로 돌아가는 방법이므로 사용할 수 없음
• 조회 전용 쿼리를 사용하면 된다. → 조회를 위한 별도의 DAO를 만들고 DAO의 조회 메서드에 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩한다.

애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이때는 캐시를 적용하거나 조회 전용 저장소를 따로 구성해야한다.

 

 

3.5 애그리거트 간 집합 연관

애그리거트 간 1:N 과 M:N 연관에 대해 살펴보자. 이 두 연관은 컬렉션을 이용한 연관이다.

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

public class Category {
    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);
    }
}

• Category에 속한 모든 Product를 조회하게 되는데 이때 Product 개수가 수만 개 정도로 많다면 실행 속도가 급격히 느려져 성능저하가 나타날 것이다.
• 그래서 개념적으로 1:N 관계라도 1:N 관계를 실제 구현에 반영하지는 않는다.

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

1:N 연관처럼 M:N 연관도 실제 요구사항을 고려하여 구현에 포함시킬지 결정해야한다.

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

 

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

 

도메인 기능을 애그리거트에 구현할 수도 있다.

//Store 클래스에서 Product 애그리거트를 생성하는 코드
public class Store extends Member {
    public Product createProduct(ProductId id, ... ) {
        if (!account.isBlocked()) {
            throw new StoreBlockedException();
        }
        return new Product(id, account.getId(), ...);
    }
}

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

//상품 정보를 입력하는 응용 서비스
public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store account = accountRepository.findStoreById(req.getStoreId());
        checkNull(account);
        ProductId id = productRepository.nextId();
        Product product = account.createProduct(id, account.getId(), ...); // Store에서 직접 생성
        productRepository.save(product);
        return id;
    }
}

• 응용 서비스에서 Store의 상태를 확인하지 않는다. → Store 가 Product를 생성할 수 있는지 확인하는 도메인 로직은 Store에 구현하였다.
• Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store 만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
• 도메인의 응집도가 높아졌다.

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