[Domain Driven Design] 9. 애그리거트 루트 (Aggregate Root)

애그리거트

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

 

[예시]

주문 애그리거트를 보자. 

Order 엔티티 - 총 금액 totalAmounts를 갖고있다.

OrderLine 밸류 - 개별 구매 상품의 개수인 quantity와 금액인 price를 갖고있다.

구매할 상품의 개수를 변경하면 한 OrderLine의 quantity를 변경하고 더불어 Order의 totalAmounts도 변경해야한다. 그렇지 않으면 다음 도메인 규칙을 어기고 데이터 일관성이 깨진다. 

 

 

루트 애그리거트

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

애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다.

 

https://velog.io/@freesky/DDD-Start-%EC%95%A0%EA%B7%B8%EB%A6%AC%EA%B1%B0%ED%8A%B8

주문 애그리거트에서 루트 역할을 하는 엔티티는 Order이다. OrderLine, ShippingInfo, Orderer 등 주문 애그리거트에 속한 모델은 Order에 직접 또는 간접적으로 속한다.

 

 

도메인 규칙과 일관성

애그리거트 루트가 단순히 애그리거트에 속한 객체를 포함하는 것으로 끝나는 것은 아니다. 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.

 

애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다. 예를들면 주문 애그리거트는 배송지 변경, 상품 변경과 같은 기능을 제공하고, 애그리거트 루트인 Order가 이 기능을 구현한 메서드를 제공한다.

 

애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야한다. 배송이 시작되기 전까지만 배송지 정보를 변경할 수 있다는 규칙이 있다면, 애그리 거트 루트인 Order의 changeShoppingInfo() 메서드는 이 규칙에 따라 배송 시작 여부를 확인하고 규칙을 충족할때만 배송지 정보를 변경해야한다.

 

...

public void changeShippingInfo(ShippingInfo newShippingInfo) {
    verifyNotYetShipped();
    setShippingInfo(newShippingInfo);
    Events.raise(new ShippingInfoChangedEvent(number, newShippingInfo));
}

private void verifyNotYetShipped() {
    if (!isNotYetShipped())
        throw new AlreadyShippedException();
}

public boolean isNotYetShipped() {
    return state == OrderState.PAYMENT_WAITING || state == OrderState.PREPARING;
}

...

 

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

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

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

ShippingInfo si = order.getShippingInfo()

if (state != OrderState.PATMENT_WATTING && state != OderState.WATTING) {
	throw IllegalArguementException()
}

si.setAddress(newAddress);

일관성을 지키기 위해 if문을 추가했지만, 이렇게 되면 동일한 검사 로직을 여러 응용 서비스에서 중복으로 구현할 가능성이 높아진다. 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 롱직을 구현하게 만들려면 도메인 모델에 대해 다음의 두가지를 습관적으로 적용해야한다.

• 단순히 필드를 변경하는 set 메서드를 공개(public) 범위로 만들지 않는다.
  • 공개 set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킨다. 도메인 로직이 한 곳에 응집되지 않으므로 코드를 유지보수 할 때에도 분석하고 수정하는데 더 많은 시간이 필요하다. 공개 set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다. set 형식의 메서드가 아닌 cnacel, changePassword와 같이 의미가 더 잘 드러나는 이름을 사용하는게 더 좋다.
• 밸류 타입은 불변으로 구현한다.
  • 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다. 애그리거트 외부에서 내부 상태를 함부로 바꾸지 못하므로 애그리거트의 일관성이 깨질 가능성이 줄어든다.
  • 밸류 객체가 불변이면 밸류 객체의 값을 변경하는 방법은 새로운 밸류 객체를 할당하는 것 뿐이다. 애그리거트 루트가 제공하는 메서드에 새로운 밸류 객체를 전달해서 값을 변경해야한다.

ShippingInfo si = order.getShippingInfo()
si.setAddress(newAddress); // 불변일 경우, 컴파일 에러

// 호출
public void changeShippingInfo(ShippingInfo newShippingInfo) {
    verifyNotYetShipped();
    setShippingInfo(newShippingInfo);
    Events.raise(new ShippingInfoChangedEvent(number, newShippingInfo));
}

// private 
 private void setShippingInfo(ShippingInfo shippingInfo) {
    if (shippingInfo == null) throw new IllegalArgumentException("no shipping info");
    // 새로운 객체 ShippingInfo로 변경
    this.shippingInfo = shippingInfo;
}

이렇게하면, 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능하다.

 

 

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

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다. 예를 들어 Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용한다.

private void calculateTotalAmounts() {
    this.totalAmounts = new Money(orderLines.stream()
            .mapToInt(x -> x.getAmounts().getValue()).sum());
}

또 다른 예시로, 회원을 표현하는 Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지를 확인할 것이다.

public void changePassword(String oldPw, String newPw) {
    if (!password.match(oldPw)) {
        throw new IdPasswordNotMatchingException();
    }
    this.password = new Password(newPw);
    Events.raise(new PasswordChangedEvent(id.getId(), newPw));
}

 

애그리거트 루트가 구성요소의 상태만 참조하는 것은 아니다. 기능 실행을 위임하기도 한다. OrderLines 엔티티에 getTotalAmount(), changeOrderLine() 메서드가 있다고 가정해보자.

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

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

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

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

OrderLines lines = order.getOrderLine();

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

이 코드는 주문의 OrderLine 목록이 바뀌는데, 총합은 바뀌지 않는 버그를 만든다. 이런 버그가 생기지 않도록 하려면 애초에 애그리거트 외부에서 OrderLine 목록을 변경할 수 없도록 OrderLines를 불변으로 구현하면 된다. 

 

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

 

 

트랜잭션 범위

트랜잭션 범위는 작을수록 좋다. 한 트랜잭션이 한개 테이블을 수정하는 것과 세개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생한다. 한개 테이블을 수정하면 트랜잭션 충돌을 막기위해 잠그는 대상이 한개 테이블의 한 행으로 한정되지만, 그 이상의 테이블을 수정하면 그 대상이 더 많아진다는 것이다. 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하며, 전체적인 성능을 떨어뜨리게된다.

 

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

 

한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 의미한다. 한 애그리거트에서 다른 애그리거트를 수정하면 결과적으로 두개의 애그리거트를 한 트랜잭션 안에서 수정하게 되므로, 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안된다.

 

[예시]

배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능이 있다고 해보자. 이때 주문 애그리거트는 회원 애그리거트의 정보를 변경하면 안된다.

public class Order{
	private Orderer orderer;

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

 

이것은 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다. 애그리거트는 최대한 서로 독립적이여야 하는데, 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다. 결합도가 높아지면 높아질수록 수정 비용이 증가하므로, 애그리거트에서 다른 애그리거트의 상태를 변경하지 말아야한다.

 

 

만약 부득이하게 한 트랜잭션으로 두개 이상의 애그리거트를 수정해야 한다면?

다른 애그리거트를 직접 수정하지 말고 응용 서비스에서 두 애그리거트를 수정하도록 구현한다.  

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) {
			order.getOrderer().getCustomer().changeAddress(newShippingInfo.getAddress());
		}
	}
}

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

 

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

 

1) 팀 표준

팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.

 

2) 기술 제약

기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야한다.

 

3) UI 구현의 편리

운영자의 편리함을 위해 주문 목록에서 여러 주문의 상태를 한번에 변경하고 싶다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야한다.