CH03 애그리거트

애그리거트

계속 비슷한 설명이 이어지는데 이번 장은 애그리거트에 대해서 상세한 설명이 있었다. 중복되는 내용을 제외하고 나머지만 정리한다.

애그리거트는 도메인 이해를 쉽게 이해하는데 도움이 된다. 저수준 레벨에서 도메인을 이해하기 전에 큰 단위들로 먼저 전체 도메인을 조망할 수 있게 해주는 단위이다.

앞에서도 다뤘지만 애그리거트에 속한 구성요소(ENTITY, VALUE)는 애그리거트와 함께 생성되고 소멸된다. 즉, 동일하거나 유사한 라이프사이클을 갖고 있다.

책에서 주의를 주고 있는 점이 있는데 바로 'A가 B를 갖는다'고 해서 반드시 A와 B가 같은 애그리거트는 아니라는 것이다. 책에서 예시로 들고 있는 것은 Product 와 Review 인데 둘의 생성 및 변경 주체가 다르기도 하고 유사한 라이프사이클을 갖고 있지도 않다. 그래서 같은 애그리거트라고 할 수 없다. 하지만 Product 는 Review 가지는 구조이긴 하다.

그래서 애그리거트 단위를 구성할 때 이러한 점을 유의하여야 한다. 저자 경험상 대부분의 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았고 두 개 이상의 엔티티로 구성되는 애그리거트는 드물었다고 한다.

애그리거트 루트

애그리거트 루트라는 용어를 루트 엔티티와 자꾸 혼용 되고 있는데, 앞에서도 살펴 보았듯이 애그리거트 내에서 대표로서 애그리거트가 제공해야할 기능을 제공하고 상태를 갖고 일관된 규칙을 보장하는 역할을 하는 엔티티가 루트 엔티티이며 애그리거트 루트라고도 부른다.

각 애그리거트에는 오직 하나의 루트 엔티티가 존재하며 이 루트 엔티티가 애그리거트에 속한 모든 ENTITY, VALUE 들에 접근하여 애그리거트 전체가 제공해줘야할 기능을 처리한다.

도메인 규칙과 일관성

다시 강조하지만 루트 엔티티의 핵심 책임은 애그리거트의 일관성을 유지하는 것이다. 일관성을 유지한다는 것은 해당 애그리거트에 속한 ENTITY, VALUE 들이 가진 고유의 도메인 규칙이 외부에 의해서 어겨지지 않고 각자의 규칙대로 일관되게 처리시킨다는 것을 의미한다.

루트 엔티티의 역할이 '애그리거트의 일관성을 유지하는 것'이라는 것을 조금 더 쉽게 이해하기 위해서 일관성을 깨트리는 예시를 살펴보자. 주문 애그리거트에서 '배송지 변경은 배송이 아직 시작하기 전에만 가능하다'는 도메인 규칙이 있다고 했을때, 아래와 같이 코드를 작성할 수 있다.

public class Order {
    
    public void changeShippingInfo(ShippingInfo newShippingInfo) {
        verifyNotYetShipped();
        setShippingInfo(newShippingInfo);
    }

    private void verifyNotYetShipped(){
        if(state != OrderState.PAYMENT_WAITING || state != OrderState.PREPARING) 
            throw new IllegalArgumentException("already shipped");
    }
}

Order의 changeShippingInfo() 만을 통해서 기능을 수행하면 무조건 verifyNotYetShipped()를 거쳐서 일관된 도메인 규칙을 지킬 수 있다. 하지만 여기서 아래와 같이 외부에 노출된 setter 로 배송지를 마음대로 바꾸게 되면 verifyNotYetShipped() 를 통해서 적용하는 도메인 규칙을 적용하지 못하게 된다. 즉, 도메인 규칙의 일관성이 깨지게 되는 것이다.

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

그리고 VALUE 를 불변으로 만들지 않으면 외부에서의 상태 변경이 가능해지기 때문에 위와 비슷한 맥락에서 일관성이 깨질 여지가 발생한다.

정리하자면 애그리거트의 루트 엔티티는 애그리거트의 일관성을 유지시키는데 핵심 책임이 있고 이를 위해서는 아래 두 가지 원칙을 지켜야 한다.

필드를 변경하는 setter 를 public 으로 노출시키면 안된다.
VALUE 는 무조건 불변 객체로 만든다.

트랜잭션의 범위

일반적인 이상적인 트랜잭션 범위

트랜잭션의 범위는 일반적으로 당연히 작을수록 좋다. 성능 이슈와 롤백 이슈 두 가지 때문이다. 트랜잭션이 범위가 작을수록 트랜잭션 처리를 위해서 필요한 자원의 점유시간이 짧아지기 때문에 다른 트랜잭션이 해당 자원에 빨리 접근할 수 있다. 이 덕분에 자원 이용률이 높아지고 시스템의 전체적인 처리량이 향상된다.

그리고 트랜잭션 범위가 작을수록 문제 발생시 롤백의 범위도 작아지기 때문에 데이터 일관성 유지가 더 쉽다.

DDD 에서의 트랜잭션 범위

DDD 관점에서도 동일한 이유가 적용된다. 이를 애그리거트 관점에서 보면 하나의 트랜잭션에서 하나의 애그리거트만 변경하도록 해야 한다. 위에서 언급한 일반적으로 트랜잭션의 범위가 작아야하는 두 가지 이유가 적용된다. 하나의 트랜잭션에서 변경하는 애그리거트 수가 많을 수록 트랜잭션의 범위가 많다는 의미가 되기 때문이다.

그리고 하나의 트랜잭션에서 두 애그리거트를 어쩔 수 없이 변경해야 할 경우 하나의 애그리거트가 다른 애그리거트를 변경하는 주체가 되어서는 안된다. 이렇게 되면 애그리거트간 결합도가 높아져서 수정비용이 크게 발생하게 되며 애초에 애그리거트 자체가 해당 군집의 독립성을 보장하는 단위인데 다른 애그리거트에 의존하는 형태가 되어버리기 때문이다.

public class Order {

    private Orderer orderer;

    public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddrAsMemberAddr) {
        verifyNotYetShipped();
        setShippingInfo(newShippingInfo);
        if (useNewShippingAddrAsMemberAddr) {
            // 다른 애그리거트의 상태를 변경하면 안된다.
            orderer.getMember().changeAddress(newShippingInfo.getAddress());
        }
    }
}

위 코드는 Order 애그리거트가 자신의 기능을 수행하면서 Order 애그리거트의 Customer 를 통해서 Member 애그리거트를 변경하는 모습이다. Order 애그리거트와 Member 애그리거트간에 결합도가 올라가고 수정비용이 더 많이 발생한다.

부득이하게 하나의 트랜잭션에서 두 애그리거트 이상을 변경해야한다면 아래와 같이 응용서비스 계층에서 두 애그리거트가 각자 주체가 되어서 변경하도록 처리해야 한다.

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

책에서는 위와 같이 응용계층을 이용하는 것 말고도 도메인 이벤트를 통해서 동기 혹은 비동기 방식으로 다른 애그리거트를 변경하는 것도 추천하는데 10장에 나오는 이야기라서 여기서는 따로 정리하지 않는다.

리포지터리와 애그리거트

애그리거트는 독립적인 하나의 도메인 카테고리에 해당하는 개념이기 때문에 데이터의 영속화와 조회를 책임지는 리포지터리 역시 하나의 애그리거트에 대해서 하나만 존재하는 것이 원칙상 맞다. 시스템에 존재하는 리포지터리의 수는 존재하는 애그리거트의 수(루트 엔티티의 수)와 같은 것이 원칙적으로 옳다.

그리고 당연한 이야기이지만 리포지터리는 각자 책임지는 애그리거트에 대해서 완전한 도메인 모델에 대한 조회와 완전한 도메인의 영속화 이 두 가지는 반드시 기능해줘야 한다.

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

객체 직접 참조시 발생하는 문제

아래와 같이 애그리거트가 다른 애그리거트를 참조하는 일은 매우 흔하게 발생한다.

이렇게 애그리거트를 객체로 직접 참조하게 되면 아래와 같은 문제가 발생한다.

편한 탐색 오용 쉽게 말해서 객체 탐색으로 바로 다른 애그리거트에 접근이 가능하기 때문에 위에서 언급한 것처럼 특정 애그리거트가 다른 애그리거트에 직접 변경을 하도록 처리할 가능성이 생긴다.(편한 객체 탐색이 불러오는 오용(애그리거트가 다른 애그리거트를 변경시키는 일))
확장의 어려움 나는 실무에서 이런 일은 없었는데, 애그리거트마다 어떤 것은 RDB 어떤 것은 Document DB 와 같이 다른 기술을 사용할 경우 객체 탐색이 되지 않을 수 있기 때문에 나중에 확장(이렇게 두 기술을 사용하기위해 기술을 분리하는 경우)할 때 수정 비용이 많이 발생한다.(객체 탐색을 해서 처리했던 로직들이 사용이 불가능해지므로 수정비용이 크게 발생한다)

(책에서는 '성능에 대한 고민' 도 있는데 이건 DDD 에 관한 이야기가 아니라 ORM 자체에 대한 이슈라서 너무 당연한 이야기인 것 같아서 뺐다)

ID를 이용한 간접 참조 방식

그래서 해결책으로 책에서는 아래와 같이 ID를 이용한 간접 참조 방식을 소개하고 있다.

이렇게 처리하면 위에서 언급한 문제들이 어떻게 해결될까?

편한 탐색 오용 객체 참조가 원천적으로 아예 불가능해짐으로써 편한 탐색 오용의 문제가 발생할 수 없다.
확장의 어려움 어떤 DB 시스템이든 PK 를 사용하는 일반적인 형태는 같으므로 필요시 ID를 이용해서 검색하면 되기 때문에 처음부터 저렇게 설계를 해두면 아래와 같이 확장(시스템의 이원화)도 쉽게 가능하다.

개인적으로는 굳이 ID 참조를 사용하면 득보다 실이 더 많은 것 같다는 생각이 든다. 애그리거트간 다른 DB 시스템을 사용할 일도 드물기도 하고 설령 사용하게 된다고 해도 객체 참조를 적극적으로 사용해서 이것이 주는 이점을 최대한 누리고, 다른 DB 시스템을 사용하게 될 경우 저렇게 겹치는 애그리거트만 이중 관리를 하는게 차라리 득이 더 클 것 같다.

그리고 편한 탐색 오용 문제도 ID 참조를 할 경우 구조적으로 아예 불가능한 것은 참 좋지만 객체 탐색으로 누릴 수 있는 이점을 다 버리게 되는데 이것 역시 득보다는 실이 큰 것 같다. 편한 탐색 오용 문제는 객체 탐색이 되더라도 그냥 개발을 원칙을 잘 지켜서 애그리거트가 다른 애그리거트를 변경시키지 않게 개발을 하면 되는 것 같다.

정리하자면 객체 직접 탐색시 이러한 문제(편한 탐색 오용, 확장의 어려움)가 있을 수 있고 이를 ID를 통한 간접 참조로 해결할 수 있다는 사실을 인지만 해두면 될 것 같다.

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

public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store account = accountRepository.findStoreById(req.getStoreId());
        checkNull(account);
        if (!account.isBlocked()) {
            throw new StoreBlockedException();
        }
        ProductId id = productRepository.nextId();
        Product product = new Product(id, account.getId(), ...);
        productRepository.save(product);
        return id;
    }
}

위 코드를 보면 account 가 blocked 인 경우 Product 생성을 못하는 도메인 로직이 응용 계층에 노출되어 있다. 설령 이것이 도메인 서비스라고 해도 도메인 계층 내에 속할 수 있는 도메인 로직을 굳이 노출시킨 형태이다.

이를 아래와 같이 애그리거트를 팩토리로 활용할 경우 도메인 로직을 도메인 계층에 응집시킬 수 있다.

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

public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store account = accountRepository.findStoreById(req.getStoreId());
        checkNull(account);
        ProductId id = productRepository.nextId();
        Product product = accout.createProduct(id, /*...*/);
        productRepository.save(product);
        return id;
    }
}

이렇게 처리를 해도 되고 DDD 세레나데 수업에서 배운 방식처럼 create 를 static method 형태로 제공하고 파라미터로 ~Validator 를 받아서 모든 validation 을 ~Validator 내에서 처리하는 것도 괜찮은 처리 방식이라 생각한다.

아래는 내가 프로젝트 때 처리한 ~Validator 사용 방식 코드의 일부이다.

Auction

    public static Auction create(User hostUser, AuctionCreateCommand auctionCreateCommand, AuctionValidator auctionValidator) {
        auctionValidator.validateAuction(auctionCreateCommand);
        AuctionItem targetAuctionItem = AuctionItem.create(auctionCreateCommand.getAuctionItem(), auctionValidator);
        Auction auction = Auction.builder()
                .auctionType(auctionCreateCommand.getAuctionType())
                .auctionItem(targetAuctionItem)
                .endTime(auctionCreateCommand.getEndTime())
                .auctionStatusType(AuctionStatusType.ACTIVE)
                .description(auctionCreateCommand.getDescription())
                .auctionImageUrl(auctionCreateCommand.getAuctionImageUrl())
                .isDisplayed(YesNoType.Y)
                .hostUser(hostUser)
                .bids(new ArrayList<>())
                .build();
    
        return auction;
    }

AuctionValidator

    public void validateAuction(AuctionCreateCommand auctionCreateCommand) {
        LocalDateTime now = LocalDateTime.now();
        long gap = now.until(auctionCreateCommand.getEndTime(), ChronoUnit.MINUTES);

        if ((applicationEnvironment.isReleaseProfile() && gap < INVALID_AUCTION_END_TIME_MINUTES)) {
            throw new IllegalArgumentException("경매 종료시각은 현재 시각으로부터 최소 5분 이후여야 합니다.");
        }

        if ((applicationEnvironment.isReleaseProfile() && gap < 0)) {
            throw new IllegalArgumentException("경매 종료시각은 현재시점보다 미래 시각이어야 합니다.");
        }
    }

~Validator 는 해당 애그리거트의 여러 기능 수행시 필요한 validation 전부를 책임진다. Bean 으로 만들어지므로 필요한 리포지터리를 주입 받아서 validation 수행시 필요한 조회(당연히 오직 조회만 써야한다)를 통해서 validation에 필요한 다른 애그리거트의 데이터를 확인할 수 있다.

PreviousCH02 아키텍처 개요 NextCH04 리포지터리와 모델 구현

Last updated 1 year ago