애그리거트

애그리거트

 

- 도메인 객체 모델이 복잡해지면 전반적인 구조나 큰 수준에서 도메인 간 관계를 파악하기 어려워짐. -> 코드 변경/확장 난이도 상승

- 애그리거트를 통해 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들 수 있음.

- 애그리거트를 통해 관련 객체를 하나의 군으로 묶을 수 있고, 상위 수준에서 도메인 모델 간 관계 파악 가능

- 애그리거트는 모델을 이해하는 데 도움을 줄 뿐 아니라 일관성 관리 기준도 됨.

- 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클 가짐

- 애그리거트는 경계를 가짐 -> 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않음

- 애그리거트 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항

- 도메인 규칙에 따라 함께 생성되는 구성 요소는 한 애그리거트에 속할 가능성이 높음

- 대개 한 애그리거트는 한 개의 엔티티 객체만 갖는 경우가 많음

 

애그리거트 루트

도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야

루트 엔티티 :

애그리거트의 대표 엔티티, 애그리거트에 속한 모든 객체가 일관된 상태를 유지하기 위한 애그리거트 전체를 관리한 주체

- 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것

- 이를 위해 루트는 애그리거트가 제공해야 할 도메인 기능을 구현

 

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

1. 단순히 필드를 변경하는 set 메서드를 public 범위로 만들지 않기

2. 벨류 타입은 불변으로 구현

 

- 팀 표준이나 기술 제약으로 불변으로 구현할 수 없다면 패키지나 protected 범위로 한정해서

외부에서 실행할 수 없도록 제한할 수도 있음

- 한 트랜젝션에서는 한 개의 애그리거트만 수행, 애그리거트에서 다른 에그리거트를 변경하지 않음

- 애그리거트는 최대한 서로 독립적이어야. 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도 높아짐

- 부득이하게 두 개 이상 애그리거트를 수정해야 한다면 응용 서비스에서 두 애그리거트를 수정하도록 구현

 

리포지터리와 애그리거트

리포지터리는 애그리거트 단위로 존재

한 애그리거트를 저장할 때 애그리거트 루트와 모든 구성요소에 매핑되는 테이블에 데이터를 저장

 

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

애그리거트에서 다른 애그리거트를 참조한다는 것은 다른 애그리거트의 루트는 참조한다는 것과 같음

 

애그리거트 직접 참조 문제점:

1. 편리함을 오용할 수 있다는 문제가 있음. 한 애그리거트가 자기 자신으로 한정해서 관리해야

2. 성능 측면 고민 필요. JPA를 사용시 지연-즉시로딩 방식 등 다양한 경우의 수 고려

3. 확장 측면에서도 문제. JPA를 사용하면 단일 기술만 사용해야

 

위 세 가지 문제를 완화하는 방법이 ID를 이용한 다른 애그리거트를 참조하는 것

- ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결됨

- ID 참조 방식을 사용하면 N+1 조회 문제가 발생할 수 있음. 조회 전용 쿼리를 만들어 join을 사용해서 로딩 진행

 

애그리거트 간 집합 연관

- 개념적으로는 애그리거트 간 1-N 연관이 있더라도 성능 문제 때문에 실제 구현에 반영하지 않음

- 차라리 역으로 N-1 연관 지어 구현하면 됨

 

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

 

Service 단에서 Product 생성 판단 로직과 생성 로직을 각기 호출하고 있음

Store라는 Product를 만드는 팩토리를 구현하여 생성에 대한 책입은 팩토리로 이전

 

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 애그리거트에 팩토리 메서드를 구현하는 것도 좋은 방법