[EFUB 4기 BE Lead] 도메인 주도 개발 시작하기 - 3. 애그리거트

EFUB 4기 BackEnd Lead_ 도메인 주도 개발 스터디

• 스터디 커리큘럼: 최범균, "도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지"
• 2주차 과제: Chapter 3. 애그리거트, Chapter 4. 리포지토리와 모델 구현

---

Chapter 3. 애그리거트

• Keywords: 애그리거트, 애그리거트 루트와 역할, 애그리거트와 리포지터리, ID를 이용한 애그리거트 참조

3.1 애그리거트

도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고, 상위 수준에서 모델 간의 관계를 파악하기 어렵다. => 해결책: 애그리거트.

애그리거트: 관련된 객체를 하나의 군으로 묶는 것. 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만듦으로써 상위 수준에서 도메인 모델 간의 관계를 쉽게 파악할 수 있다.

• 모델 이해 도움 + 일관성 관리 기준 (단순한 구조로 쪼갬. 도메인 기능을 확장하고 변경할 때에도 드는 노력 감소.)
• 경계를 갖는 독립된 객체 군 (객체는 한 애그리거트에만 속할 수 있다. 각 애그리거트는 자신을 관리할 뿐 다른 애그리거트를 관리하지 않음.)
• 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 가짐 (애그리거트에 속한 구성요소는 대부분 함께 생성되고 함께 제거됨.)

애그리거트 경계를 설정 할 때 유의할 점: 도메인 규칙, 요구사항
- 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다. (함께 생성, 변경되는 빈도가 높은 객체)
- 'A가 B를 갖는다'로 설계할 수 있는 요구사항이 있을 때, 이것이 두 객체가 반드시 한 애그리거트에 속함을 의미하는 것은 아니다. ('상품이 리뷰를 갖는다'의 경우 둘은 함께 생성되지 않고 함께 변경되지도 않는다. 변경 주체도 다르다.)
- 애그리거트는 한 개 이상의 엔티티 객체를 가질 수 있다. (한 개인 경우가 많음)

 

3.2 애그리거트 루트

도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다. (ex. 데이터 일관성 지켜야 함)

애그리거트 루트: 애그리거트에 속한 모든 객체가 일관된 상태를 유지하도록 하기 위해 애그리거트 전체를 관리하는 주체.

- 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접/간접적으로 속하게 된다. (ex. 주문 애그리거트의 루트: Order)

3.2.1 도메인 규칙과 일관성

애그리거트 루트의 핵심 역할: 애그리거트의 일관성이 깨지지 않도록 한다.

• 이를 위해 애그리거트 루트는 애그리거트에서 제공해야 할 도메인 기능을 구현한다. (ex. 주문 애그리거트가 배송지 변경, 상품 변경 같은 기능을 제공하고, 루트인 Order에서는 구현한 메서드를 제공)
• 애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안 된다. 이것은 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이 된다. (상태 확인 로직을 응용 서비스에 구현할 수도 있지만 이렇게 되면 동일한 검사 로직을 여러 응용 서비스에서 중복으로 구현할 가능성이 높고, 유지 보수 측면에서 좋지 않다.)
• 애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다. (ex. 배송지 변경 기능을 구현한 Order의 changeShippingInfo() 메서드: 배송 시작 여부를 확인하고 규칙을 충족할 때만 배송지 정보를 변경해야 한다. void 자료형 verifyNotYetShipped();을 호출해 확인함 - 규칙을 충족하지 않았다면 예외가 던져짐)

따라서, 일관성 유지를 위해 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드려면 도메인 모델에 대해 다음의 두 가지를 습관적으로 적용해야 한다.

1. 단순히 필드를 변경하는 set 메서드를 public 범위로 만들지 않는다.
(스프링에서 setter 어노테이션 사용을 지양해야 하는 이유)
- 공개 set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킨다. 도메인 로직이 한 곳에 응집되지 않으므로 코드를 유지 보수할 때에도 분석하고 수정하는 데 더 많은 시간이 필요하다.

2. 밸류 타입은 불변으로 구현한다.
- (필드가 private이고 공개 set 메서드 사용 없이 불변으로 구현 시,) 애그리거트 루트에서 밸류 객체를 구해도 애그리거트 외부에서 밸류 객체의 상태를 직접 변경할 수 없다. 밸류 객체의 내부 상태를 변경하려면 애그리거트 루트가 제공하는 메서드를 통해 새로운 밸류 객체를 할당 후 전달해서 값을 변경해야 한다.

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

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

1. 애그리거트 루트가 구성요소의 상태를 참조
   - ex. Order에 필드로 OrderLine
   - ex. Member에 필드로 Password
2. 구성요소에 기능 실행을 위임
   1) Order에 필드로 있던 List<OrderLine> orderLines를 별도 클래스로 분리하기 위해 OrderLines 클래스를 신규 생성하고, changeOrderLines() 메서드로 필드의 상태 변경을 구현했다.
   2) 이후 Order는 필드로 OrderLines orderLines를 가지게 되었으며 Order의 changeOrderLines() 메서드는 orderLines 필드에 상태 변경을 위임하는 식으로 동작한다. orderLines.changeOrderLines(newLines).
   +) 외부에서 get-으로 객체를 구할 수 있다면 change-와 같은 메서드를 호출해 값을 함부로 변경할 수 있음에 주의하자. (해결법: 애그리거트 외부에서 OrderLine 목록을 변경할 수 없도록 OrderLines를 불변으로 구현. 또는 OrderLines의 변경 기능을 패키지/protected 범위로 한정해서 외부에서 실행할 수 없도록 제한하는 방법도 있다.)

3.2.3 트랜잭션 범위

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

- 테이블을 수정해야 할 때 트랜잭션 충돌을 막기 위해 대상을 잠가야 하는데(1개 테이블의 1개 행 등) 이것이 성능에 영향을 끼친다. (수정할 테이블 수가 많음 -> 잠금 대상이 많음 -> 동시에 처리할 수 있는 트랜잭션 개수가 줄어들어 성능(처리량) 감소)

(2) 한 트랜잭션에서는 한 개의 애그리거트만 수정해야 한다. 즉 한 애그리거트에서 다른 애그리거트를 변경하면 안 된다.

- 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 높아지며, 한 번에 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어진다.

- 만약 한 애그리거트 내부에서 다른 애그리거트의 상태를 변경한다면, 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하게 되는 것이다. (애그리거트는 최대한 서로 독립적이어야 하는데, 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다. 향후 수정 비용 증가.)

 

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

* 경우에 따라 한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 것도 고려할 수 있다.
- 상황의 예: 팀 표준, 기술 제약, UI 구현의 편리
- 이런 경우에는 응용 서비스에서 두 애그리거트를 수정하도록 구현한다. (애그리거트에서 다른 애그리거트를 직접 수정하지 말고; @Transactional 활용 예시 코드)

 

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

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현한다.

So 객체의 영속성을 처리하는 리포지토리는 애그리거트 단위로 존재한다.

- ex. Order와 OrderLine을 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 각각의 리포지터리를 따로 만들지 x.

Order가 애그리거트 루트, OrderLine은 애그리거트에 속하는 구성요소이므로 Order를 위한 리포지터리만 존재한다.

 

리포지터리 두 기본 메소드

• save: 애그리거트 저장 // 새로운 애그리거트를 만들어서 저장소에 애그리거트를 영속화할 때
• findById: ID로 애그리거트를 구함 // 애그리거트를 사용하려고 저장소에서 애그리거트를 읽어올 때
  + 이외에 다양한 조건으로 애그리거트를 검색하는 메서드, 애그리거트를 삭제하는 메서드 등을 추가 가능.

어떤 기술로 리포지터리를 구현하느냐에 따라 애그리거트의 구현도 영향을 받는다.

- JPA를 사용하면 데이터베이스 관계형 모델에 객체 도메인 모델을 맞춰야 할 때도 있다.

 

리포지터리의 특징(유의점)

• 애그리거트가 개념적으로 하나이므로, 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  - ex. Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블 뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장해야 한다.
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
  - 애그리거트의 필드나 값이 올바르지 않을 경우 기능 실행 도중 널포인터 예외와 같은 문제가 발생할 수 있다.
• 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다.
  - 애그리거트에서 여러 객체를 변경했는데 저장소에 일부 변경이 반영되지 않는다면 데이터의 일관성이 깨진다.
  - RDBMS를 이용해 리포지터리를 구현하면 트랜잭션을 이용해 애그리거트의 변경이 저장소에 반영되는 것을 보장할 수 있다.

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

한 객체가 다른 객체를 참조하는 것처럼, 애그리거트끼리도 참조 관계가 존재한다.

- 애그리거트 관리 주체는 애그리거트 루트이므로, 한 애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트를 참조한다는 것. (=애그리거트 루트만이 참조되어질 수 있다. 능동적으로 참조하는 것은 루트가 아니어도 가능)

 

필드를 이용해 다른 애그리거트를 직접 참조하면 구현이 편리하다. 

- JPA의 @ManyToOne, @OneToOne 애너테이션: 연관된 객체를 로딩하는 기능 제공

- ORM 기술 덕에 애그리거트 루트에 대한 참조를 쉽게 구현할 수 있고, 필드(또는 get 메서드)를 이용한 참조로 다른 애그리거트의 데이터를 쉽게 조회할 수 있다.

- 한편, 문제점도 있다.

 

필드를 이용한 애그리거트 참조가 야기할 수 있는 문제점: 편한 탐색 오용, 성능에 대한 고민, 확장 어려움

1. 편리함을 오용할 수 있다.
   - 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다 (수정하고자 하는 유혹) => 한 애그리거트에서 다른 애그리거트의 상태를 변경하게 되면 애그리거트 간 의존 결합도 높이고 애그리거트의 변경을 어렵게 만든다.
2. 성능에 대해 고민해야 한다.
   - JPA 사용 시 참조한 객체를 즉시 로딩(eager)과 지연 로딩(lazy)의 두 가지 방식으로 로딩할 수 있다.
   - 다양한 경우의 수를 고려해서 연관 매핑, JPQL/Criteria의 로딩 전략을 결정해야 한다.
   (두 로딩 방식 중 무엇을 사용할지는 애그리거트의 어떤 기능을 사용하느냐에 따라 달라진다.
   *즉시 로딩이 유리: 단순히 연관된 객체의 데이터를 함께 화면에 보여주는 경우
   *지연 로딩이 유리: 애그리거트의 상태를 변경하는 기능을 실행하는 경우)
3. 확장
   - 사용자가 늘고 트래픽이 증가하면 하위 도메인별로 시스템을 분리해야 한다. 이 과정에서 하위 도메인마다 서로 다른 DBMS 쓰기도 하고, 다른 종류의 데이터 저장소 쓰기도 한다. -> 이렇게 되면 단일 기술을 쓸 수 없어짐

이런 세 가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다.

ID를 이용한 참조는 DB 테이블에서 외래키로 참조하는 것과 비슷하게 다른 애그리거트를 참조할 때 ID를 사용한다.

 

ID 참조를 사용할 시의 장점

1. 모델 복잡도 감소
- 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 애그리거트 경계를 명확히 한다. 애그리거트 간 의존을 제거한다.

2. 구현 복잡도 감소
- 다른 애그리거트를 직접 참조하지 않으므로 로딩 방식을 고민하지 않아도 된다. 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해 로딩하면 된다. (애그리거트 수준에서 지연 로딩을 하는 것과 동일한 결과.)

3. 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 근원적으로 방지 가능.
- 외부 애그리거트를 직접 참조하지 않기 때문에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.

4. 애그리거트별로 다른 구현 기술을 사용하는 것이 가능해진다.

- 각 도메인을 별도 프로세스로 서비스하도록 구현할 수 있다.

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

다른 애그리거트를 ID로 참조할 때의 문제점: 조회 속도가 느림

N+1 조회 문제: '조회 대상이 N개일 때 N개를 읽어오는 한 번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다'

더 많은 쿼리를 실행하기 때문에 전체 조회 속도가 느려지는 원인이 된다.

이 문제가 발생하지 않도록 하기 위해서는 조인을 사용해야 한다

- 조회 전용 쿼리를 사용하면 된다.

ex. 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩.

3.5 애그리거트 간 집합 연관

애그리거트 간 1-N과 M-N 연관. 이 두 연관은 컬렉션을 이용한 연관이다. (ex. 카테고리-상품: 1-N)

성능 문제 때문에 개념적인 연관대로 구현하지 않고 더 나은 방법을 이용한다.

• 1-N 관계: 상품 입장에서 자신이 속한 카테고리를 N-1로 연관 지어 구한다.
  - Product에 Category로의 연관을 추가하고, 이를 이용해 categoryId가 지정한 카테고리 식별자인 Product 목록을 구한다.
• M-N 연관: (개념적으로는 양방향 연관이 존재하지만) 실제 구현에서는 단방향 M-N 연관만 적용한다.
  - RDBMS에서 M-N 연관을 구현하려면 조인 테이블을 사용한다.

JPA에서 ID참조를 이용해 M-N 단방향 연관 구현하는 예시

 

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

요구사항: 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성하도록 하고 싶다.

-> 상품을 생성하려고 할 때에 상점의 차단 상태 유무를 확인해야 한다.

Product를 생성하는 기능을 Store 애그리거트에 옮겨보자.

-> 응용 서비스에서 더 이상 Store 상태를 확인하지 않아도 되게 되었다. Store에서 Product를 생성할 수 있는 도메인 로직을  구현하고 있기 때문에, Store 안에서 바로 차단 유무를 알 수 있다. 추후 Product 생성 가능 여부를 확인하는 도메인 로직을 변경하더라도 응용 서비스는 영향을 받지 않는다.

 

애그리거트를 팩토리로 만들 시의 장점: 응용 서비스에서 상태를 확인하지 않아도 되게 되어, 도메인 로직 변경시 도메인 영역의 엔티티만 변경하면 된다. 응용 서비스는 영향을 받지 않는다.

- 애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해 보자.

- 또는 Store 애그리거트에서 Product 애그리거트를 직접 생성하지 않고 다른 팩토리에 위임할 수도 있다. (ProductFactory 클래스 생성)