애그리거트

DDD START CHAPTER 3 정리

애그리거트, 덩어리

서비스를 개발하기 위해서는 도메인 객체들을 만든다. 서비스가 성장하고 시간이 흐르면 도메인 객체 모델은 복잡해지고 개별 구성요소 위주로 모델을 이해하게 된다. 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요하다. 애그리거트는 관련된 객체를 하나의 군으로 묶어준다. 수많은 객체를 애그리거트로 묶어서 바라보면 좀 더 상위수준에서 도메인 모델 간의 관계를 파악할 수 있다.

애그리거트의 경계, 어떤 것들을 하나의 덩어리로 볼 것인가?

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

경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다. 예를 들어 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문 시점에 함께 생성된다. 따라서 이들은 한 애그리거트에 속한다. 애그리거트는 보통 한 개의 엔티티 객체만 같은 경우가 많다.

애그리거트 루트

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

도메인 규칙과 일관성

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

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

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

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

위와 같은 코드는 도메인 규칙을 무시하고 DB테이블에서 직접 데이터를 수정하는 것과 같은 결과를 만든다. 즉, 논리적인 데이터 일관성이 깨지게 된다.

애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들자!

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

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

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

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

public class OrderLines {
	private List<OrderLine> lines;
    public Money getTotalAmounts(){ 
    		return new Money(
            		orderLines.stream()
        			.mapToInt(ol -> ol.getPrice() * ol.quantity())
                    .sum());
	}
    public void changeOrderLines(List<OrderLine> newLines){
    	this.lines = newLines;
	}
}

만약 Order가 getOrderLines()와 같이 OrderLines를 구할 수 있는 메서드를 제공하면 애그리거트 외부에서 OrderLines의 기능을 실행할 수 있게 된다.

OrderLines lines = order.getOrderLines();

//외부에서 애그리거트 내부 상태 변경!
//order의 totalAmounts 값이 OrderLines와 일치하지 않게 됨
lines.changeOrderLines(newOrderLines);

외부 접근 xx, 불변

트랜잭션 범위, 한 애그리거트 씩 수정하자

트랜잭션 범위는 작을수록 좋다.

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

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

리포지터리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야한다. 애그리거트에 속한 모든 구성요소를 위한 테이블에 데이터를 저장하고 조회할 수 있어야 한다.

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

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

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

한 객체가 다른 객체를 참조하는 것처럼 애그리거트도 다른 애그리거트를 참조한다. 애그리거트의 관리주체가 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 애그리거트의 루트를 참조한다는 것과 같다.

두 가지 방식의 참조

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

필드를 이용한 참조

public class Order{
	private Orderer orderer;
    ...
}

public class Orderer{
	private Member member;
    private String name;
    ...
}

public class Member{
	...
}

예를 들어, 주문 애그리거트에 속해 있는 Orderer는 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.

필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다. 예를 들어, 주문 정보 조회 화면에서 회원 아이디를 이용해서 링크를 제공한다고 하자. 이 경우, 다음과 같이 Order로부터 시작해서 회원 아이디를 구할 수 있다.

order.getOrderer().getMember().getId();

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

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

1. 편한 탐색 오용

한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다. 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다.

2. 성능에 대한 고민

JPA를 사용할 경우 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다. 두 로딩 방식 중 무엇을 사용할지 여부는 애그리거트의 어떤 기능을 사용하느냐에 따라 달라진다. 단순히 연관된 객체의 데이터를 함께 화면에 보여주어야 하면 즉시 로딩이 조회 성능에 유리하지만, 애그리거트의 상태를 변경하는 기능을 실행하는 경우에는 불필요한 객체를 함께 로딩할 필요가 없으므로 지연 로딩이 유리하다.

3. 확장 어려움

초기에는 단일 서버에 단일 DBMS로 서비스를 제공하는 것이 가능하다. 사용자가 늘고 트래픽이 증가하면 자연스레 하위 도메인 별로 시스템을 분리하기 시작한다. 이 과정에서 하위 도메인마다 서로 다른 DBMS를 사용할 가능성이 높아진다. 심지어 하위 도메인마다 다른 종류의 데이터 저장소를 사용하기도 한다. 이는 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.

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

public class Order{
	private Orderer orderer;
    ...
}

public class Orderer{
	private MemberId memberId;
    private String name;
    ...
}

public class Member{
	private MemberId id;
	...
}

ID를 이용한 참조는 DB 테이블에서의 외래키를 사용해서 참조하는 것과 비슷하게 다른 애그리거트를 참조할 때 ID 참조를 사용한다는 점이다. 단, 애그리거트 내의 엔티티를 참조할 때는 객체 레퍼런스로 참조한다.

ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 땜문에 모델의 복잡도를 낮춰준다. 또한, 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과도 있다.
구현 복잡도도 낮아진다. 다른 애그리거트를 직접 참조하지 않으므로 애그리거트간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다. 참조하는 애그리거트가 필요하면 응용 서비스에서 아이디를 이용해서 로딩하면 된다.
ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지할 수 있다. 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.
애그리거트별로 다른 구현 기술을 사용하는 것도 가능해진다.

N+1 조회 문제

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

Customer customer = customerRepository.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, customer, product);
                        }).collect(toList());

예를 들어, 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 하는데, 이를 처리할 때 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자. 위 코드의 주문 개수가 10개면 주문을 읽어오기 위한 1번의 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행한다.

이 문제는 전용 조회 쿼리 사용하여 한 번의 쿼리로 필요한 데이터를 로딩하면 된다. (FetchJoin)
애그리거트 마다 서로 다른 저장소를 사용하는 경우에는 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이런 경우 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.

애그리거트 간 집합 연관

1:N

개념적으로는 애그리거트 간에 1:N 연관이 있더라도 성능상의 문제 때문에 애그리거트 간의 1:N 연관을 실제 구현에 반영하는 경우는 드물다. 이 경우 주로 N:1 연관으로 문제를 해결한다.

public void testSave(){
        Member member1 = new Member("member1");
        Member member2 = new Member("member2");

        Team team1 = new Team("team1");
        team1.getMemberList().add(member1);
        team1.getMemberList().add(member2);

        em.persist(member1); // insert member1
        em.persist(member2); // insert member2
        em.persist(team1); // insert team1, update - member1.fk, member2.fk


}

Team과 Member 연관에서 1:N관계를 생각해보자. Team에서 List<Member>를 가지고 있다고 하자. 외래키는 Member테이블에 존재하게 되는데 Team에 Member를 추가할 때 업데이트 쿼리가 한번 더 나가는 문제가 발생한다.
N:1관계로 바꿔서 해결하자. (Member에 TeamId를 추가)

'Design Patterns' 카테고리의 다른 글

게이트웨이 패턴, 서비스 스텁 패턴 (0)	2020.10.08
지연로드(Lazy Load) 패턴 (0)	2020.10.04
식별자 맵 패턴 (0)	2020.10.03
작업단위 패턴 (0)	2020.10.03
애그리거트 트랜잭션관리 (0)	2020.09.20

주간이성훈

🏄‍♂️

애그리거트