[DDD Start!] 3. 애그리거트

애그리거트

• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요함
• 일관성을 관리하는 기준이 됨. 복잡도가 낮아지는 만큼 도메인 기능을 확장/변경하는데 필요한 노력이 줄어듬.

---

• 애그리거트는 독립된 객체 군
  • 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않음.
  • 각 애그리거트는 자기자신을 관리할 뿐 다른 애그리거트를 관리하지 않음
• 경계 설정
  • 설정 기준: 도메인 규칙 & 요구사항
  • A가 B를 갖는다 (상품-리뷰) ≠> A B 가 한 애그리터그에 속한다
    • 함께 생성되지 않고 함께 변경되지 않음
    • 변경하는 주체도 다름
    • B의 변경이 A에 영향을 주지 않음
    → 다수의 애그리거트가 한개의 엔티티 객체만 갖는 경우가 많으며, 두개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재함

애그리거트 루트

• 애그리거트는 여러 객체로 구성되기 때문에 한 객체만 상태가 정상이어선 안됨 → 일관성 유지!
• → 애그리거트 전체를 관리할 주체가 필요: 루트 엔티티

루트 엔티티(에그리거트 루트)

• 애그리거트의 대표 엔티티
• 애그리거트에 속한 객체는 루트 엔티티에 직/간접적으로 속함
• 애그리거트 일관성 유지를 책임짐 → 도메인 규칙에 따라 도메인 기능(메서드)을 구현(void verify~~~)
• 루트 엔티티가 아닌 객체가 다른 객체를 직접 변경하면 안됨

---

애그리거트 루트를 통해서만 도메인 로직을 구현하기 위한 방법

1. 도메인 모델의 엔티티나 밸류에 setter 를 public 으로 만들지 않는다.
2. 밸류 타입은 불변으로 구현한다.

• 도메인 로직이 도메인 객체에 응집될 수 있도록 setter를 private으로 선언
• set 형식의 이름을 갖는 공게 메서드 사용하지 않으면 의미가 더 잘 드러나는 이름을 사용하게 됨
  • ex. cancel, changePassword...
• 밸류 객체가 불변이면 값을 변경하는 방법은 → 새로운 객체를 할당하는 것 뿐
• 불변으로 구현할 수 없는 경우: 변경기능을 패키지나 protected 범위로 한정하도록 제한
• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성.

---

트랜잭션

• 한 트랜잭션에서는 한개의 애그리거트만 수정해야한다.
• 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어짐 (잠금대상이 많아짐)

리포지터리와 애그리거트

• 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재함.
  • 애그리거트 내 각각의 객체가 별도의 DB테이블에 존재한다고 해서 레포지터리를 각각 만들지 않는다
• 레포지터리 제공 메서드
  • save : 애그리거트 저장
  • findById : 애그리거트 구함

애그리거트 간 참조

• 애그리거트 간 참조 = 애그리거트의 루트를 참조
• 방법1) 필드를 통해 구현
  • 연관된 객체 로딩(JPA: @ManyToOne, @OneToOne...)
  • 필드를 이용한 애그리거트 참조의 문제
    1. 편한 탐색 오용
       • 다른 애그리거트의 상태를 쉽게 변경하게 됨 → 애그리거트 관리범위는 자기자신으로 한정되어야함.
    2. 성능에 대한 고민
       • 지연 로딩(lazy) vs 즉시 로딩(eager)
    3. 확장 어려움
       • 사용자/트래픽이 늘수록 부하 분산을 위해 하위 도메인별로 시스템을 분리하기 시작 → 하위 도메인 마다 다른 DBMS / 다른 종류의 데이터 저장소를 사용할 가능성 생김 → JPA와 같은 단일 기술 사용할 수 없어짐
    ⇒ ID를 이용한 간접 참조
• 방법2) ID를 이용한 간접 참조
  • 모든 객체가 참조로 연결되지 안혹, 한 애그리거트에 속한 객체들만 참조로 연결됨 → 애그리거트 간 경계를 명확히 하고, 물리적 연결을 제거
  • 참조가 필요할때만 응용서비스에서 아이디를 통해 로딩하면 됨(=지연로딩)
  • 문제점
    • 여러 애그리거트를 읽어야 할 때 조회 속도가 문제 될 수 있음 ⇒ N+1 조회
      • 주문 읽어오기(1) + 주문별 상품 읽어오기(N)
      • 지연 로딩의 문제점
      ⇒ (X) 조인 사용하여 해결: ID 참조 → 객체 참조로 변경 : 다시 방법1로 돌아가게됨
      • jpa : jpql 사용 or sql 특화 기능 사용이 필요한 경우: 조회 부분만 MyBatis 이용
    • ⇒ (O) 전용 조회 쿼리를 사용 : 별도 DAO를 만들고 조회 메서드에서 세타조인을 이용해서 로딩
• 애그리거트마다 서로 다른 저장소 사용하는 경우
  • 한번의 쿼리로 관련 애그리거트 조회 불가
  • 캐시 적용 or 조회 전용 저장소 따로 구성
    • 코드 복잡해지지만, 시스템 처리량 높일수 있음

애그리거트 간 집합 연관

1:N or N:1

• 1 → N : 카테고리별 프로덕트 조회
  • Set 과 같은 컬렉션으로 표현 가능 ⇒ but, 성능 문제 발생
• N → 1 : 프로덕트의 카테고리 조회
  • ID를 이용한 연관 설정

M:N

• 양쪽 애그리거트에 컬렉션으로 연관 생성 → 하지 않아도 된다.. 요구사항을 고려하여 필요한 쪽에만 연관을 적용하자.
• RDBMS: 조인테이블 사용
• JPA
  • @CollectionTable, @ElementCollection , @JoinColumn등과 같은 매핑설정을 사용
  • JPQL - member of 연산자 이용

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

• 애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야한다면ex. store(상점) 의 상태(데이터)에 따라 product(물건)을 생성하는 조건이 있는 경우 : store 에 product를 생성하는 팩터리 메서드를 추가
• → 애그리거트에 팩토리 메서드를 구현하자