Book/도메인 주도 개발 시작하기

3장

버스는그만 2023. 10. 29. 16:52

3.1 애그리커트

주요 도메인 요소 간의 관계를 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 상위 수준에서 모델이 어떻게 엮여 있는지 알아야 전체 모델을 망가뜨리지 않으면서 추가 요구사항을 모델에 반영할 수 있는데, 세부적인 모델만 이해한 상태로는 코드를 수정하는 것이 꺼려지기 때문에 코드 변경을 최대한 회피하는 쪽으로 요구사항을 협의하게 된다.

복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데 그 방ㅂ버이 바로 애그리커트다. 애그리거트는 관련된 객체를 하나의 군으로 묶어 준다. 

애그리거트로 복잡한 모델을 관리

애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다. 예를들어 Order를 생성했는데 Orderer나 OrderLine 등을 생성하지 않는 경우는 없다. 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리커트에 속한 구성요소는 대부분 함꼐 생성하고 함꼐 제거한다.

 위의 그림을 보면 애그리커트는 경계를 갖는다. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다. 흔히 'A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 하지만 'A가 B를 갖는다'로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.

 좋은 예는 상품과 리뷰다. 상품 상세페이지에 리뷰가 보이지만 상품과 리뷰는 함계 생성되지 않고, 함꼐 변경되지도 않는다. 게다가 Product를 변경하는 주체가 상품담당자라면 Review를 생성하고 변경하는 주체는 고객이다. Review의 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 때문에 이 둘은 한 애그리거트에 속하기 보다는 서로 다른 애그리거트에 속한다.

3.2 애그리거트 루트

주문 애그거트에는 다음을 포함한다.

  • 총 금액을 갖고 있는 Order 엔티티
  • 개별 구매 상품의 수인 quantity와 금액인 price를 갖고 있는 OrderLine 밸류

애그리거트는 여러 객체로 구성되기 떄문에 한 객체만 상태가 정상이면 안된다. 도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다. 주문 애그리거트에서는 OrderLine을 변경하면 Order의 totalAmouts도 다시 계산해서 총 금액이 맞아야 한다. 애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티이다. 애그리거트 루트 엔티티는 애그리거트의 대표 엔티티다. 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다. Order는 OrderLine, ShippingInfo, Orderer 등 주문 애그리거트에 속한 모델은 Order에 직접 또는 간접적으로 속한다.

 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다. 이를 위해 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다. 예를 들어 애그리거트는 배송지 변경, 상품 변경과 같은 기능을 제공하고, 애그리거트 루트인 Order가 이 기능을 구현한 메서드를 제공한다. 예를 들어 배송이 시작되기 전까지는 배송지 정보를 변경할 수 있다는 규칙이 있다면, 이 규칙에 따라 배송 시작 여부를 확인하고 규칙을 충족할 떄만 배송지 정보를 변경해야 한다.

public class Order {
    
    public void changeShippingInfo(ShippingInfo newShippingInfo) {
        verifyNotShipped();
        setShippingInfo(newShippingInfo);
    }
    
    private void verifyNotShipped() {
        if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
            throw new IllegalStateException("aleady shipped");
        }
    }
}

애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다. 이것은 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이다.

일관성을 지키기 위해 아래과 같이 상태 확인 로직을 응용 서비스에 구현할 수도 있다. 하지만 이렇게 되면 동일한 검사 로직을 여러 응용 서비스에서 중복으로 구현할 가능성이 높아져 유지 보수에 도움이 되지 않는다.

        ShippingInfo si = order.getShippingInfo();
        
        if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
            throw new IllegalStateException("aleady shipped");
        }
        
        si.setAddresss(newAddress);

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

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

 공개 set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킨다. 도메인 로직이 한 곳에 응집되지 않으므로 코드를 유지 보수할 때에도 분석하고 수정하는 데 더 많은 시간이 필요하다.

 공개 set 메서드를 만들지 않는 것의 연장으로 밸류는 불변 타입으로 구현한다. 밸류 타입의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.

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

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성할 뿐만 아니라 기능 실행을 위임하기도 한다. 예를 들어 구현 기술의 제약이나 내부 모델링 규칙 때문에 OrderLine 목록을 별도 클래스로 분리했다고 해보자.

public class OrderLines {
    private List<OrderLine> lines;
    
    public Money getTotalAmouts(){ ;}
    
    public void changeOrderLines(List<OrderLine> newLines) {
        this.lines = newLines;
    } 
        
}

위와 같이 Order의 changeOrderLines 메서드는 다음과 같이 내부의 orderLines 필드에 상태 변경을 위임하는 방식으로 기능을 구현한다.

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

만약 Order가 getOrderLies()와 같이 ORderLines를 구할 수 있는 메서드를 제공하면 애그리거트 외부에서 OrderLines의 기능을 실행할 수 있게 된다. 이런 버그가 생기지 않도록 하려면 애초에 애그리거트 외부에서  OrderLine 목록을 변경할 수 없도록 ORderLines를 불변으로 구현하면 된다.

 팀 표준이나 구현 기술의 제약으로 OrderLines를 불변으로 구현할 수 없다면 OrderLines의 변경 기능을 패키지나 protected 범위로 한정해서 외부에서 실팽할 수 없도록 제한하는 방법도 있다. 보통 한 애그리거트에 속하는 모델은 한 패키지에 속하기 때문에 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능을 실행하는 것을 방지 할 수 있다.

3.2.3 트랜잭션 범위

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

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

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

@Service
public class ServiceImpl {
    
    @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());
        }
    } 
}

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

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

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

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

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

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

애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야한다. 애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 애그리거트에서 두 개의 객체를 변경했는데 저장소에는 한 객체에 대한 변경만 반영되면 데이터 일관성이 깨지므로 문제가 된다.

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

한 객체가 다른 객체를 참조하는 것처럼 애그리거트도 다른 애그리거트를 참조한다. 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다. 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.

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

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

애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다는 점이다. 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다. 그런데 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다음 코드처럼 구현의 편리함 때문에 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.

public class Order {
    private Orderer orderer;
    public void changeOrderLines(ShippingInfo newShippingInfo, boolean useNewShippingAddrAsMemberAddr) {
        if(useNewShippingAddrAsMemberAddr) {
            // 다른 애그리거트의 상태를 변경
            orderer.getMember().changeAddress(newShippingInfo.getAddress());
        }
    }
}

한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다. 또한 직접 참조하면 성능관 관련된 여러 가지 고민을 해야 한다는 것이다. JPA에서는 참조 객체를 지연 로딩과 즉시 로딩, 두 가지 방식으로 로딩할 수 있으며 두 로딩 방식 중 무엇을 사용할지는 애그리거트의 어떤 기능을 사용하느냐에 따라 달라진다. 단순히 화면 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리하지만 애그리거트의 상태를 변경하는 기능을 불필요한 객체를 함계 로딩할 필요가 없으므로 지연 로딩이 유리할 수 있다. 이런 다양한 경우의 수를 고려해서 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다.

마지막으로  확장할 경우 다른 DBMS나 JPA를 사용하지 않을 경우 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.

이런 세 가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다. 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다. 또한 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다.

구현 복잡도 또한 직접 참조하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않다도 되기 때문에 낮아진다. 참조하는 애그리거트가 필요하면 응요 서비스에서 ID를 이용해서 로딩하면 된다.

ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함꼐 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.

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

ID로 참조할 경우 참조하는 여러 애그리거트를 읽을 떄 조회 속도가 문제 될 수 있다. 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽으면 한 DBMS에 데이터가 있다면 조인을 이용해서 한 번에 모든 데이터를 가져올 수 있음에도 불구하고 주문마다 상품 정보를 읽어오는 쿼리를 실행한다.

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

위의 코드는 주문 개수가 10개면 주문을 읽어오기 위한 1번의 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행한다. 한번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행하는 N + 1 조회 문제인데 ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는 데 지연 로딩과 관련된 대표적인 문제가 N+1 조회 문제이다. 이 문제가 발생하지 않도록 하려면 조인을 사용해야 한다. 조인을 사용하는 가장 쉬운 방법은 ID  참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 사용하도록 매핑 설정을 바꾸는 것이다. 하지만 이 방식은 애그리거트 간 참조를 ID 참조 방식에서 객체 참조 방식으로 다시 되돌아 오는 것이다.

 ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 조회 전용 쿼리를 사용하면 된다. 예를 들어 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩하면 된다. 즉시 로딩이나 지연 로딩과 같은 로딩 전략을 고민할 피료 없이 조회 하면에서 필요한 애그리거트 데이터를 한 번의 쿼리로 로딩할 수 있다. 쿼리가 복잡하거나 SQL에 특화된 기능을 사용해야 한다면 조회를 위한 부분만 마이바티스와 같은 기술을 이용해서 구현할 수도 있다.

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

3.5 애그리거트 간 집합 연관

애그리거트 간 1-N 관계는 Set과 같은 컬렉션을 이용해서 표현할 수 있다. 그런데 개념적으로 존재하는 애그리거트 간의 1-N 연관을 실제 구현에 반영하는 것이 요구사항을 충족하는 것과는 상관없을 때가 있다. 특정 카테고리에 속한 상품 목록을 보여주는 요구사항에서 한 번에 전체 상품을 보여주기보다는 페이징을 이용해 제품을 나눠서 보여준다. 만약 카테고리에 속한 모든 Product를 조회할 경우 Product 개수가 수만 개 정도로 많다면 실행할 때마다 실행 속도가 급격히 느려져 성능에 심각한 문제를 일으키기 때문에 애그리거트 간의 1-N 연관을 실제 구현에 반영하지 않는다.

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

M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.(자세한 것은 4장에서 계속....)

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

위의 코드는 Product를 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리되어 있다. 도메인 로직 처리가 응용 서비스에 노출되었다. Store가 Product를 생성할 수 있는지를 판단하고 Product를 생성하는 것은 논리적으로 하나의 도메인 기능인데 이 도메인 기능을 응용 서비스에서 구현하고 있는 것이다.

@Service
public class ServiceImpl {

    @Transactional
    public void PRoductId registerNewPRoduct(NewProductRequest req) {
        Store store = storeRepository.findById(req.getStoreId());
        checkNull(store);
        if(store.isBlocked()) {
            throw new StoreBlockedException();
        }
        
        ProductId id = productRepository.nextId();
        Product product = new Product(...);
        productRepository.save(product);
        return id;
    }
}

논리적으로 하나의 도메인 기능인데 이 도메인 기능을 응용 서비스에서 구현하고 있는 것이다.
이 도메인 기능을 넣기 위한 별도의 도메인 서비스나 팩토리 클래스를 만들 수도 있지만 이 기능을 Sotre 애그리거트에 구현할 수도 있다. Product를 생성하는 기능을 Store 애그리거트에 다음과 같이 옮겨보자.

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

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

@Service
public class ServiceImpl {

    @Transactional
    public void ProductId registerNewPRoduct(NewProductRequest req) {
        Store store = storeRepository.findById(req.getStoreId());
        checkNull(store);
        if(store.isBlocked()) {
            throw new StoreBlockedException();
        }

        ProductId id = productRepository.nextId();
        Product product = store.createProduct(id, ...);
        productRepository.save(product);
        return id;
    }
}

앞선 코드의 차이점이라면 응용 서비스에서 더 이상 Sotre의 상태를 확인하지 않는다는 것이다. 이제 Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다. 도메인의 응집도도 높아졌다.

애그리거트가 갖가 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해보자. Product의 경우 제품을 생성한 Store의 식별자를 필요로 한다. Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면  Store 애그리거트에서 Product 애그리거트를 직접 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.