Chapter 3 애그리거트

도메인 주도 개발 시작하기 3장을 요약한 내용입니다.

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }

3.1 애그리거트

• 온라인 쇼핑몰 시스템을 개발할 때 상위 수준 개념을 이용해 전체 모델을 정리하면 전반적인 관계를 이해하는 데 도움이 된다.
• 
• 상위 수준 모델을 개별 단위로 변환
  • 상위 수준에서 개념을 파악하려면 더 오랜 시간이 걸림
  • 더 많은 코드와 도메인 전문가와 대화를 통해 상위 수준에서 모델 간 관계가 이해하기 좋음
• 백 개 이상의 테이블을 한 장의 ERD에 모두 표시하면 테이블간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움이 있다.
  • 도메인 객채 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준의 도메인간의 관계를 파악하기 어려움
  
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요
  • 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.
  • 수많은 객체를 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 간이 관계를 파악할 수 있다.
  • 
• 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다.
  • 주문 애그리거트를 만들려면 Order, OrderLine, Orderer, 와 같은 관ㄹ련 객체를 함께 생성해야 한다.
  • Order는 생성했는데 ShippingInfo는 만들지 않거나 ShippingInfo를 생성하면서 Orderer를 생성하지 않은 경우는 없다.
  • 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
• 애그리거트는 경계를 갖는다.
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
  • 애그리거트는 독립된 객체 군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
  • 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만 주문 애그리거트에서 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지 않는다.
• 경계를 생성할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문시점에 함께 생성되므로 한 애그리거트에 속한다.
• 흔히 ‘A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
• 상품 상세 페이지에 들어가면 상품 상세와 리뷰 내용을 보여줘야 하는 요구사항
  • Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다.
  • Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다.
  • Product 변경하는 주체가 상품 담당자라면 Review를 생성하는 주체는 고객이다.
  • Review 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 한 애그리거트에 속하기 보다 서로 다른 애그리거트에 속한다.
  • 
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만, 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 애그리거트의 실제 크기는 줄어든다.
  • 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많았으며 두 개이상의 엔티티로 구성되는 애그리거트는 드물었다.

3.2 애그리거트 루트

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

3.2.1 도메인 규칙과 일관성

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

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

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

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

  • 여러 응용 서비스에 중복으로 구현할 가능성이 높은 코드

  ShippingInfo si = order.getShippingInfo();
  if (state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING) {
  	throw new IllegalArgumentException();
  }
  si.setAddress(newAddress);
  

• 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대한 두가지를 습관적으로 적용해야 한다.
  • 단순히 필드를 변경하는 set 메서드를 공개 범위로 만들지 않는다.
  • 밸류 타입은 불변으로 구현한다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 일관성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않으면 의미가 들어나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • set 형식의 공개 메서드를 사용하지 않으면 자연스럽게 cancel, chagnePassword 처럼 의미가 잘 들어나느 이름을 사용하는 빈도가 높아짐
• 밸규는 불변 타입으로 구현하면 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없다.
• ShippingInfo si = order.getShippingInfo(); si.setAddress(newAddress); // ShippingInfo가 불변이면, 이 코드는 컴파일 에러
• 밸류 객체가 불변이면 새로운 밸류 객체를 할당하는 방법밖엔 없다.
  • 밸류 타입의 내부 상태를 변경하려면 애그리거트 루트를 통해서만 가능

  public class Order {
  	private ShippingInfo shippingInfo; 
  
  	public void changeShippingInfo(ShippingInfo newShippingInfo) {
  		verifyNotYetShipped();
  		setShippingInfo(newShiipingInfo);
  	}
  	
  	private void setShippingInfo(ShippingInfo newShippingInfo) {
  		// 밸류가 불변이면 새로운 객체를 할당해서 값을 변경
  		// 불변이므로 this.shippingInfo.setAddress와 같은 코드를 사용할 수 없다. 
  		this.shippingInfo = newShippingInfo;
  	}
  }
  

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

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성
• Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
• public class Order { private Money totalAmount; private List<OrderLine> orderLines; private void calculateTotalAmounts() { int sum = orderLines.stream() .mapToInt(ol -> ol.getPrice * ol.getQuantity()) .sum(); this.totalAmounts = new Money(sum); } }
• Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지 확인
• 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); } }
• 애그리거트 루트가 구성요소의 상태만 참조하는 것은 아님
  • 기능 실행을 위임하기도 함
  • OrderLines는 changeOrderLines와 getTotalAmounts() 같은 기능을 제공

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

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

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

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

3.2.3 트랜잭션 범위

• 트랜재션 범위는 작을수록 좋다
  • 한 트랜잭션이 한 개 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교하면 성능에서 차이가 발생
  • 트랜잭션 충돌을 막기 위해 잠그는 대상이 한개 에티블의 한행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아지낟.
• 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아짐
  • 애그리거트 갯수가 많이질수록 전체 처리량이 떨어지게 됨
• 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
  • 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능
    • 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
    • 애그리거트는 최대한 서로 독립적이여야 한다.
    • 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

    public class Order {
    	private Orderer orderer;
    
    	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
    		verifyNotYetShipped();
    		setShippingInfo(newShippingInfo);
    
    		if (useNewShippingAddressAsMemberAddr) {
    			order.getMember().changeAddress(newShppingInfo.getAddress());
    		}
    	}
    }
    

• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지말고 응용 서비스에서 두 애그리거트를 수정하도록 구현
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.shipTo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = findMember(order.getOrderer()); member.changeAddress(newShippingInfo.getAddress()); } } }
• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다.
• 한 트랜잭션에서 한 개의 애그리거트를 변경하는 것을 권장하지만, 다음 경우에는 한 트랜잭션에서 두개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
  • 팀 표준: 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
  • 기술 제약: 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • UI 구현의 편리: 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.

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

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.
• Order와 OrderLine은 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 Order와 OrdreLine을 위한 리포지터리를 각각 만들지 않는다.
• Order가 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재
• 어떤 기술을 이용해서 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.
• ORM 기술 중 하나인 JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공 해야함
  • Order 애그리거트는 OrderLine, Orderer 등 모든 구성 요소를 포함하고 있어야 한다.

  // 완전한 Order를 제공
  Order order = orderRepository.findbyId(orderId);
  
  // order가 온전한 애그리거트가 아니면 기능 실행 도중 NullPointerException과 같은 문제가 발생
  order.cancel();
  

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

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

• 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조하는 것과 같다
• 애그리거트 간의 참조는 필드를 통해 쉽게 구현할 수 있다
  • 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.
  • 
• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 주문 정보에서 회원 ID를 구할 수 있다.

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

• 필드를 이용한 애그리거트 참조는 문제가 발생할 수 있다.
  • 편한 탐색 오용
  • 성능에 대한 고민
  • 확장 어려움
• 애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
  • 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.

  public class Order {
  	private Orderer orderer;
  
  	public void shipTo(ShippingInfo newShippingInfo, boolean useNewShippingAddressAsMemberAddr) {
  		verifyNotYetShipped();
  		setShippingInfo(newShippingInfo);
  
  		// 구현이 쉬워진다는 것 때문에 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다. 
  		if (useNewShippingAddressAsMemberAddr) {
  			order.getMember().changeAddress(newShppingInfo.getAddress());
  		}
  	}
  }
  

  • 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.
• 애그리거트를 직접 참조하면 성능과 관련된 여러가지 고민을 해야 한다
  • JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
  • 단순한 연관된 객체의 데이터를 함께 보여줘야 한다면 즉시 로딩이 조회 성능에 유리
  • 애그리거트의 상태를 변경하는 기능을 실행하는 경우 불필요한 객체를 함께 로딩할 필요가 없어 지연 로딩이 유리
• 확장의 어려움
  • 하위 도메인마다 서로 다른 DBMS를 사용할 때도 있다.
  • 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음
• 세가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것
  • DB 테이블에서 외래키를 참조하는 것과 비슷하게 ID를 이용한 참조는 다른 애그리거트를 참조할 때 ID를 사용
  • 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다.
  • 
• 다른 애그리거트를 직접 조회하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.
• public class ChangeOrderService { @Transactional public void changeShippingInfo(Order id, ShppingInfo newShippingInfo, boolean useNewshippingAddrAsMemberAddr) { Order ordre = orderRepository.findById(id); if (order == null) { throw new OrderNotFoundExcepation(); } order.changeShippingInfo(newShippingInfo); if (useNewshippingAddrAsMemberAddr) { Member member = memberRepository.findById(order.getOrderer().getMemberId()); member.changeAddress(newShippingInfo.getAddress()); } } }
• ID를 이용한 참조방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장
  • 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장
  • 

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

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다.
• 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 함
  • 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자

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

  • 주문 개수가 10개면 주문을 읽어오기 위한 쿼리와 주문별로 각 상품을 읽어오기 위한 10번의 쿼리를 실행
• N+1 조회 문제 발생
  • 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.
  • 조인을 사용하는게 가장 쉬운 방법이지만 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것
• ID 참조 방식에서 N+1 조회 문제 해결 방법
  • 조회 전용 쿼리를 사용
  • 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩
  • JPQL 사용 예제

  @Repository
  public class JpaOrderViewDao implements OrderViewDao {
  	@PresistenceContext
  	private EntityManager em;
  
  	@Override
  	public List<OrderView> selectByOrderer(String ordererId) {
  		String selectQuery = "
  			select 
  				new com.myshop.order.application.dto.OrdreView(o, m, p)
  			from 
  				Order o join o.orderLines ol, Member m, Product p
  			where
  				o.orderer.memberId.id = :ordererId
  				and o.order.memberId = m.id
  				and index(ol) = 0
  				and ol.productId = p.id
  			order by
  				o.number.number desc
  		"
  		TypedQuery<OrderView> query = em.createQuery(selectQuery, OrderView.class);
  		query.setParameter("ordererId", ordererId);
  		return query.getResultList();
  	}
  }
  

• 애그리거트마다 서로 다른 저장소를 사용한다면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
  • 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 하는 기법

3.5 애그리거트 간 집합 연관

• 애그리거트 간 1-N과 M-N 연관에 대해 살펴보자
  • 두 연관은 컬렉션을 이용한 연관이다.
• 특정 카테고리에 속한 상품 목록을 보여주는 요구 사항
  • 1-N 연관을 이용해 구현
  • Product 개수가 많다면 이 코드는 실행할 때마다 실행 속도가 급격히 느려져 성능에 문제가 있음

  public class Category {
  	private Set<Product> products;
  	
  	public List<Product> getProducts(int page, int size) {
  		List<Product> sortedProducts = sortById(products);
  		return sortedProduct.subList((page - 1) * size, page * size);
  	}
  
  }
  

• 애그리거트 간에 1-N 연관이 있더라도 성능 문제 떄문에 애그리거트 간의 1-N 연관은 실제 구현에 반영하지 않는다.
• 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카태고리를 N-1로 연관 지어 구분하면 된다.
  • ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Proudct 목록을 구현

  public class ProductListService {
  	public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
  		Category category = categoryRepository.findById(categoryId);
  		checkCategory(category);
  		List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
  		int totalCount = productRepository.countsByCategoryId(category.getId());
  		return new Page(page, size, totalCount, products);
  	}
  }
  

• M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다.
  • 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다.
  • 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 된다.
• RDBMS를 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
• 
• JPA를 이용하면 매핑 설정을 사용해서 ID 참조를 이용한 M-N 단반향 연관을 구현할 수 있다.
  • JPQL의 member of 연산자를 이용해 특정 Category에 속한 Proudct 목록을 구하는 기능을 구현할 수 있다.
  • :catId member of p.categoryIds는 categoryIds 컬렉션에 catId로 지정한 값이 존재하는지를 검사하기 위한 검색 조건

  @Repostiroy 
  public class JpaProductRepository implements ProductRepository {
  	@PersistenceContext
  	private EntityManager entityManager;
  	
  	@Override
  	public List<Product> findByCategoryId(CategoryId catId, int page, int size) {
  		TypeQuery<Product> query = entityManager.createQuery("
  			select 
  				p
  			from 
  				Product p
  			where
  				:catId member of p.categoryIds 
  			order by 
  				p.id.id desc
  		");
  		query.setParameter("catId", catId);
  		query.setFirstResult((page - 1) * size);
  		query.setMaxResults(size);
  		return query.getResultList();
  	}
  }
  

• @Entity @Table(name = "Proudct") public class Product { @EmbeddedId private ProductId id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) private Set<CategoryId> categoryIds; }

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

• 상품 등록 기능을 구현한 응용 서비스는 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성
  • Product 생성 가능한지 판단하는 코드와 Product를 생성하는 코드가 분리 되어 있음
  • 중요한 도메인 로직처리가 응용 서비스에 노출되어 있음

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

• Store 애그리거트에 구현
  • createProduct는 Product 애그리거트를 생성하는 팩토리 역활을 한다.
  • 팩토리 역활을 하면서 중요한 로직을 구현하고 있다.

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

• 응용 서비스에서 더 이상 Store의 상태를 확인하지 않아도 됨
  • Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다.
  • 도메인의 응집도를 높였다.
  • 애그리거트를 팩토리로 사용할 때 얻을 수 있는 장점
• Store 애그리거트가 Product 애그리거트를 생성할 때 많은 정보를 알아야 한다면 Store 애그리거트에서 Product 애그리거트를 생성하지 않고 다른 팩토리에 위임하는 방법도 있다.
• public class Store { public Product createProduct(ProductId newProductId, ProductInfo pi) { if (isBlocked()) { throw new StoreBlockedException(); } return ProductFactory.create(newProductId, getId(), pi); } }