[도메인 주도 개발 시작하기] -3장 애그리거트

3.1 애그리거트

애그리거트

• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들기 위해 상위 수준에서 모델을 조망하는 방법
  → 관련된 객체를 하나의 군으로 묶어줌
• 모델을 이해하는데 도움을 줄 뿐만 아니라 일관성을 관리하는 기준도 됨
  → 복잡한 도메인을 단순한 구조로 만들어줌
  → 복잡도가 낮아지는 만큼 도메인 기능을 확장하고 변경하는데 필요한 노려도 줄어듬

애그리거트의 경계

• 애그리거트는 경계를 갖음
  → 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않음
  → 애그리거트는 독립된 객체군이며 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않음
  ex) 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신은 관리하지만, 회원의 비밀번호를 변경하거나 상품의 가격을 변경하지는 않음
• 경계를 설정할 때 도움이 되는 것은 도메인 규칙과 요구사항
  → 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높음
  ex) 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문 시점에 함께 생성되므로 이들은 한 애그리거트에 속함
  ex) 사용자 요구사항에 따라 주문 상품 개수와 배송지를 함께 변경하기도 함. 이렇게 함께 변경되는 빈도가 높은 객체는 한 애드리거트에 속할 가능성이 높음

애그리거트 주의사항

• 'A가 B를 갖는다' 로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아님
  ex) 상품과 리뷰: 상품 상세 페이지에 들어가면 상품 상세 정보와 함께 리뷰 내용을 보여줘야 한다는 요구사항이 있을 때 Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있음. 아지만 Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않으므로 다른 애그리거트에 속함

3.2 애그리거트 루트

배경

• 애그리거트는 여러 객체로 구성되기 떄문에 한 객체만 상태가 정상이면 안 됨.
• 도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 함.

애그리거트 루트 엔티티

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

 

3.2.1 도메인 규칙과 일관성

애그리거트 루트

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

불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들기위한 습관

• 단순히 필드를 변경하는 set 매서드를 public 범위로 만들지 않는다
  → public set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킴
  → 도메인 로직이 한 곳에 응집되지 않으므로 코드를 유지 보수할 때에도 분석하고 수정하는 데 많은 시간이 필요
  → public set 메서드를 사용하지 않으면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아짐
• 밸류 타입은 불변으로 구현한다
  → 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 벨류 객체를 구해도 애그리거트 외부에서 밸류 객체릐 상태를 변경할 수 없음
  → 애그리거트 외부에서 내부 상태를 함부로 바꾸지 못하므로 애그리거트의 일관성이 깨질 가능성이 줄어듬
  → 밸류 객체가 불변이면 밸류 객체의 값을 변경하는 방법은 새로운 밸류 객체를 할당하는 것 뿐

 

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

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

• 구성요소의 상태 참조
  ex1) Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용
  ex2) 회원을 표현하는 Member 애그리거트 루트는 암호를 변경하기 위해 Password 객체에 암호가 일치하는지를 확인
• 기능 실행 위임
  ex1) OrderLine 목록을 별도 클래스로 분리했다고 가정했을 때, Order의 changeOderLine() 메서드는 내부의 orderLines 필드에 상태 변경을 위임하는 방식으로 기능을 구현할 수 있음

3.2.3 트랜잭션 범위

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

• 한 트랜잭션이 한 개의 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것을 비교해보면
  - 한 개의 테이블을 수정하면 트랜잭션 충돌을 막기 위해 잠그는 대상이 한 개 테이블의 한 행으로 한정
  - 세 개의 테이블을 수정하면 잠금 대상이 더 많아짐
  → 장금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 의미하고 이것은 전체적인 성능을 떨어뜨림

한 트랜잭션에서는 한 개의 애그리거트만 수정해야 함

• 한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 의미
• 한 애그리거트에서 다른 애그리거트를 수정하면 결과적으로 두 개의 애그리거트를 한 트랜잭션으로 수정하게 되므로, 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안됨
• ex) 배송지 정보를 변경하면서 동시에 배송지 정보를 회원 주소로 설정하는 기능: 이때 주문 애그리거트는 회원 애그리거트의 정보를 변경하면 안됨
  → 이것은 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 됨
• 만약 부득이하게 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고 응용 서비스에서 두 애그리거트를 수정하도록 구현

한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 것을 고려하는 예외사항

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

 

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

래포지터리와 애그리거트

• 애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재
• 레포지터리가 기본으로 제공하는 메서드
  - save: 애그리거트 저장
  - findById: ID로 애그리거트를 구함
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 함
  ex) Order 애그리거트와 관련된 테이블이 세 개라면 Order 애그르거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장해야 함
• 애그리거트를 구하는 레포지터리 메서드는 완전한 애그리거트를 제공해야 함
  → 리포지터리가 완전한 애그리거트를 제공하지 않는다면 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 도중에 NullPointerException과 같은 문제가 생길 수 있음
  

 

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

애그리거트 간의 참조

• 한 객체가 다른 객체를 참조하는 것처럼 애그리거트도 다른 애그리거트를 참조함
  → 애그리거트 관리 주체는 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트 루트를 참조한다는 것
• 필드를 통해 쉽게 구현 가능
  ex) 주문 애그리거트에 속해 있는 Orderer는 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조 가능    
  
  

  

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

 

필드를 이용한 애그리거트 참조의 문제점

• 편한 탐색 오용
  → 한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 됨  
  → BUT 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 함
• 성능에 대한 고민
  → JPA를 사용하면 참조한 객체를 지연(lazy) 로딩과 즉시(eager)로딩의 두가지 방식으로 로딩할 수 있음
  - 단순히 연관된 객체의 데이터를 함께 화면에 보야줘야 하면 즉시 로딩이 조회 성능에 더 유리
  - 애그리거트의 상타를 변경하는 기능을 실행하는 경우에는 불필요한 객체를 함께 로딩할 필요가 없으므로 지연 로딩이 유리
• 확장의 어려움
  → 초기에는 단일 서버에 단일 DBMS로 서비스를 제공하는 것이 가능
  → BUT 사용자가 몰리기 시작하면 부하를 분산하기 위해 하위 도메인별로 시스템을 분리해야 함
  → 이 과정에서 서로 다른 DBMS를 사용할 때도 있음
  → 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없게 됨

 

필드를 이용한 애그리거트 참조의 문제점 완화 방법

• ID를 이용해 다른 애그리거트 참조하기
  → ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결됨
• 효과
  - 애그리거트의 경계를 명확히하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춤.
  - 애그리거트 간의 의존을 제거하므로 응집도를 높여주는 효과가 있음
  - 구현 복잡도가 낮아짐: 다른 애그리거트를 직접 참조하지 않으므로 애그리거트 간 참조를 지연로딩으로 할지 즉시로딩으로 할지 고민하지 않아도 됨
  - 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지 가능: 외부 애그리거트를 직접 참조하기 않기 때문에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없기때문
  - 애그리트별로 다른 구현 기술을 사용하는 것이 가능해짐
  - 각 도메인을 별도 프로세스로 서비스하도록 구현 가능해짐

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

ID를 이용한 참조의 성능

• 다른 애그리거를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있음
  ex) 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 하는데, 이를 처리할 때 각 주문마다 상품과 회원 애그리거트를 읽어온다고 가정
  → 조인을 이용해 한번에 모든 데이터를 가져올 수 있음에도 불구하고 주문마다 상품 벙보를 읽어오는 처리를 하게 됨
• ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는 데 지연 로딩과 관련된 대표적인 문제는 N+1 조회문제임

N+1 조회 문제

• 조회 대상이 N개일 때 N개를 읽어오는 한 번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행하는 것
• 더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 됨
• 해결 방법
  1. 조인 사용: ID 참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 하도록 매핑 설정. but 이 방식은 애그리거트 간 참조를 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것임
  2. 조회 전용 쿼리 사용: 한 가지 예시로, 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터 로밍

3.5 애그리거트 간 집합 연관

애그리거트 간 1-N, M-N 관계

• 이 두 관계는 Set과 같은 컬렉션을 이용해서 표현 가능
• But 성능 문제 때문에 개념적인 연관대로 구현하지 않고 더 나은 방법을 이용

1-N 관계

• 상품 입장에서 자신이 속한 카테고리를 N-1로 연관지어 구함
  → Product에 Category로의 연관을 추가하고 그 연관을 이용해 특정 Category에 속한 Product 목록을 구하면 됨
  → 카테고리에 속한 상품 목록을 제공하는 응용 서비스는 ProductRepository를 이용해서 categoryId가 지정한 카테고리 식별자인 Product 목록을 구함

M-N 관계

• 개념적으로는 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 됨

  

  
  → 조인 테이블 사용

 

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

요구사항

• 여러 차례 신고를 당한 상점은 더 이상 물건을 등록할 수 없다.
• 응용 서비스에 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성하도록 구현한다면
  → Store가 Product를 생성할 수 있는지 판단하고 Product를 생성하는 것은 논리적으로 하나의 도메인 기능이므로
  → 도메인 로직 처리가 응용 서비스에 노출되게 된다
• Store 애그리거트에 구현한다면
  → Store 애그리거트의 createProduct()가 Product 애그리거트를 생성하는 팩토리 역할을 하게됨
  → 더 이상 응용 서비스에서 Store의 상태를 확인하지 않고 Store에서 구현하게 됨
  → Product 생성 가능 여부를 확인하는 도메로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향 X

 

3장을 마치며...

이번 3장에서는 애그리거트에 대해 깊게 다뤄보았다.

사실 아직도 애그리거트라는 개념이 명확하게 머리에 들어온 것은 아니지만 복잡한 도메인을 이해하기 쉽게 상위 수준에서 모델을 바라보는 것이라는 것은 확실히 알게 되었다.

또한, 지금까지 프로젝트를 하며 카테고리를 구현할 때 어떻게 구성해야 잘 구현한 것일지 몰라 헤맸었는데 1-N 집합 연관 관계를 이용해서 구현할 수 있다는 것을 알게 되었다. 다음에 카테고리를 구현할 땐 이 방법을 써서 구현해 봐야겠다!

또한 애그리거트 팩토리 개념도 유익했다. 어떠한 도메인 로직을 처리할 때 이 로직을 어느 부분에 구현해야하는지 잘 몰라 어려웠는데 도메인 로직을 응용 서비스 영역이 아닌 애그리거트 팩토리를 만들어 이 곳에 구현한다면 역할의 분리가 잘 된다는 것을 알게되었다.