8. • 한 애그리거트에 속한 객체는 동일한 생명 주기를 가
짐
• 애그리거트의 경계 기준은 도메인 규칙과 요구사항
• 단순한 소유 관계가 기준은 아님
• ex) 상품과 리뷰
• 일반적으로 애그리거트는 한개의 Entity 객체와 다수
의 Value 객체로 구성됨
애그리거트의 특징
9. • 애그리거트의 대표 엔티티 객체
• 애그리거트 전체의 일관성(도메인 규칙)을 관리하는 주체
• 루트는 애그리거트가 제공해야하는 도메인의 기능을 구현
• 외부 객체는 애그리거트에 속한 객체를 직접 변경하면 안됨
애그리거트 루트
(ROOT)
주문(Aggregate)
11. • 단순히 필드를 변경하는 set 메서드는 Public 안됨
• 내부 객체를 외부에 노출하지 않음
• Value 타입은 불변 객체로 구현
애그리거트를 위한 습관
12. • 트랜잭션의 범위는 작을수록 좋음
• 한 트랜잭션에서는 한 개의 애그리거트만 수정하는 것
이 유리
• 한 트랜잭션에서 2개 이상의 애그리거트를 수정이 필
요할때
• 응용 서비스에서 두개의 애그리거트를 수정하도록 구현
• 도메인 이벤트를 이용하여 비동기로 처리(10장)
트랜잭션의 범위
13. • 객체의 영속성을 처리하는 리포티터리는 애그리거트 단
위로 존재
• 리포지터리가 제공해야 하는 최소 기능
• save: 애그리거트 저장
• findById: ID로 애그리거트 조회
• 리포지터리의 구현
• RDBMS: 트랜잭션을 사용
• Mongodb: 애그리거트를 한개의 문서로 저장
리포지터리와 애그리거
트
15. • JPA 등의 연관된 객체 로딩 기능을 통해 쉽게 구현 가능
• 단점
• 애그리거트 간의 의존도를 높여 변경을 어렵게 함
• 성능 이슈가 발생할 수 있음
• 즉시 로딩 / 지연 로딩
• 확장 어려움
• 서로 다른 DBMS를 사용 or 다른 기술을 사용하는 경우 직접 구
현해야 함
애그리거트 직접 참조
16. • DB 테이블에서의 외래키를 사용 하는것과 유사
• 장점
• 애그리거트의 경계를 명확히하고, 의존도를 제거
• 구현 복잡도가 낮음
• 확장에 용이
ID를 사용한 참조
서비스에서 필요한 애그리거트를 로딩
17. • ID로 참조할 경우 여러 애그리거트를 읽어야할 때 성능 문제가 발생할
수 있음
• Ex) 고객의 주문 리스트 조회(첫 상품 정보가 표시되어야 함)
• JPA 로딩 기능 보다 전용 조회 쿼리 사용 or MyBatis 기술 이용
• 코드가 복잡해지지만 성능을 높일 수 있음
ID를 사용한 참조와 조회 성
능(JPA)
18. • 개념적인 애그리거트와 요구사항을 충족하는 것이 관계가 없는 경우가
있음
• ex) Category, Product
• 개념적으로는 Category: Product = 1: N 집합 관계
• 요구사항에 Paging이 포함된다면??
• 개념이 아니라 요구사항을 고려하여 연관 관계를 지정해야 함
애그리거트 사이의 집합
연관
19. • 애그리거트가 가진 데이터를 이용하여 다른 애그리거트를 생성할 경우
구현을 고려
애그리거트를 팩토리로
사용
20. • 최범균. DDD START! 도메인 주도 설계 구현과 핵심 개념
익히기. 서울시 마포구 (주)지앤선, 2016.
• MARTINFLOWLER.COM,
http://martinfowler.com/bliki/DDD_Aggregate.html
• Eric Evans, Domain Driven Design(이대엽 옮김). 경기도
파주시 문발로 위키북스, 2011.
References
