3장 애그리거트
3.1 애그리거트
도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다. 도메인 요소 간 관계를 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 이를 해결할 수 있는 방법이 애그리거트이다.
일관성을 관리하는 기준이 될 수 있고, 모델을 이해하는 데 도움이 된다. 애그리거트는 관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다. 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함께 생성하고 함께 제거한다.
애그리거트는 경계를 갖는다. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 애그리거트는 독립된 객체 군이며 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다. 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다. 예로 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문 시점에 함께 생성되므로 이들은 한 애그리거트에 속한다. 함께 변경되거나 생성되는 빈도 높은 객체는 한 애그리거트에 속할 가능성이 높다. 흔히 'A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 하지만 이와 같은 요구사항이 있더라도 반드시 그런 것은 아니다.
좋은 예가 있다. 상품과 리뷰다. 상품 상세 페이지에 들어가면 상품 정보와 리뷰 내용을 보여줘야 한다는 요구사항이 있을 때 Product 엔티티와 Review 엔티티가 한 애그리거트에 속한다고 생각할 수 있다. 하지만 이 둘은 함께 생성 및 변경되지도 않는다. 게다가 Product를 변경하는 주체가 상품 담당자라면 Review를 생성하고 변경하는 주체는 고객이다. 그래서 이는 서로 다른 애그리거트에 속한다.
3.2 애그리거트 루트
주문 애그리거트는 다음을 포함한다.
1) 총금액인 totalAmounts를 갖고 있는 Order 엔티티
2) 개별 구매 상품의 개수인 quantity와 금액인 price를 갖고 있는 OrderLine 밸류
- 주문 총 금액은 개별 상품의 주문 개수 X 가격의 합
애그리거트는 여러 객체로 구성되기 때문에 한 객체만 상태가 정상이면 안된다. 도메인 규칙을 지키려면 애그리거트에 속한 모든 객체가 정상 상태를 가져야 한다. OrderLine을 변경하면 Order의 totalAmounts도 다시 계산해서 총금액이 맞아야 한다. 그래서 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티이다. 애그리거트 루트 엔티티는 애그리거트의 대표 엔티티이고, 애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적을 속하게 된다.
3.2.1 도메인 규칙과 일관성
애그리거트 루트는 애그리거트의 일관성이 깨지지 않도록 하는 것이다. 이를 위해 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다. 예로 애그리거트는 배송지 변경, 상품 변경과 같은 기능을 제공하고, 애그리거트 루트인 Order가 이 기능을 구현한 메서드를 제공한다.
애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안 된다. 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 일관성을 깨는 원인이 된다. 불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들려면 아래 2가지를 습관화해야 한다.
1) 단순히 필드를 변경하는 set 메서드를 public 범위로 만들지 않는다.
2) 밸류 타입은 불변으로 구현한다.
공개 set 메서드는 도메인의 의미나 의도를 표현하지 못하고 도메인 로직을 도메인 객체가 아닌 응용 영역이나 표현 영역으로 분산시킨다. 이는 도메인 로직이 한 곳에 응집되지 않으므로 유지보수할 때 분석하고 수정하는 데 많은 시간이 필요하다.
3.2.2 애그리거트 루트의 기능과 구현
애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다. 또한 구성 요소의 상태만 참조하는 것이 아니라, 기능 실행을 위임하기도 한다. 대신 기능 실행을 위임할 때 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능을 실행하는 것을 방지할 수 있다.
3.2.3 트랜잭션 범위
트랜잭션 범위는 작을수록 좋다. 한 트랜잭션에는 한 개의 애그리거트만 수정해야 한다. 한 트랜잭션에서 한 애그리거트만 수정한다는 것은 다른 애그리거트를 변경하지 않는다는 것을 의미한다. 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 것은 좋지 않다. 최대한 서로 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.
만약 한 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 말고 응용 서비스에서 두 애그리거트를 수정하도록 구현한다. 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서도 동기나 비동기로 다른 애그리거트의 상태를 변경하는 코드를 작성할 수 있다. 아래의 경우에는 한 트랜잭션에서 두 개 이상의 애그리거트를 변경하는 것을 고려할 수 있다.
1) 팀 표준 : 팀이나 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우가 있다.
2) 기술 제약 : 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랙잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
3) UI 구현의 편리 : 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 것이다. 이 경우 한 트랜잭션에서 여러 주문 애그리거트의 상태를 변경해야 한다.
3.3 리포지터리와 애그리거트
애그리거트는 완전한 한 개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 레포지터리는 애그리거트 단위로 존재한다. 새로운 애그리거트를 만들면 저장소에 애그리거트를 영속화하고 애그리거트를 사용하려면 저장소에서 애그리거트를 읽어야 하므로, 리포지터리는 보통 아래 2가지 메서드를 기본적으로 제공한다.
1) save : 애그리거트 저장
2) findByID : ID로 애그리거트를 구함
예로 애그리거트와 관련된 테이블이 세 개라면 Order 애그리거트를 저장할 때 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소에 매핑된 테이블에 데이터를 저장해야 한다.
3.4 ID를 이용한 애그리거트 참조
한 애그리거트도 다른 애그리거트를 참조한다. 애그리거트 관리 주체는 애그리거트 루트이므로 다른 애그리거트 루트를 참조한다는 것과 같다. 애그리거트 간의 필드를 통해 쉽게 구현할 수 있는데, 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다. 하지만 필드를 이용한 애그리거트 참조는 아래와 같은 문제를 야기할 수 있다.
1) 편한 탐색 오용
2) 성능에 대한 고민
3) 확장 어려움
가장 큰 문제는 편리함을 오용할 수 있다는 것이다. 한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있다. 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다.
두 번째 문제는 애그리거트를 직접 참조하면 성능과 관련된 여러 가지 고민을 해야 한다. JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방법으로 로딩할 수 있다. 단순히 연관된 객체의 데이터를 함께 화면에 보여줘야 한다면 즉시 로딩이 조회 성능에 유리하지만 애그리거트의 상태를 변경하는 기능을 실행하는 경우에 불필요한 객체를 함께 로딩할 필요가 없으므로 지연 로딩이 유리할 수 있다.
세 번째 문제는 확장이다. 사용자가 늘고 트래픽이 증가하면 부하를 분산하기 위해 하위 도메인별로 시스템을 분리하기 시작한다. 하위 도메인마다 다른 종류의 데이터 저장소를 사용하기도 한다. 이것은 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.
이런 세 가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다. ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다. 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 때문에 모델의 복잡도를 낮춰준다. 또한 의존을 제거하므로 응집도를 높여준다.
3.4.1 ID를 이용한 참조와 조회 성능
다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽을 때 조회 속도가 문제 될 수 있다. 예로 DBMS에 데이터가 있다면 조인을 이용해서 한 번에 모든 데이터를 가져올 수 있음에도 불구하고 주문마다 상품 정보를 읽어오는 쿼리를 실행하게 된다. '조회 대상이 N일 때 N개를 읽어오는 한 번의 쿼리와 연관된 데이터를 읽어오는 쿼리를 N번 실행한다'해서 이를 N+1 조회 문제라고 부른다. ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만드는 데 지연 로딩과 관련된 대표적인 문제가 N+1 조회 문제이다.
이를 위해 조회 전용 쿼리를 사용하면 된다. 예로 데이터 조회를 위한 별도 DAO를 만들고 DAO의 조회 메서드에서 조인을 이용해 한 번의 쿼리로 필요한 데이터를 로딩하면 된다. 쿼리가 복잡하거나 SQL에 특화된 기능을 사용해야 한다면 조회를 위한 부분만 마이바티스와 같은 기술을 이용해 구현할 수도 있다.
-> 처음 JPA를 사용하면 객체 간 모든 연관을 지연 로딩과 즉시 로딩으로 처리하고 싶은 욕구가 있는데, 이는 실용적이지 않다.
애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다. 이때는 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다. 코드가 복잡해지는 단점이 있지만, 시스템의 처치량을 높일 수 있다는 장점이 있다. 특히 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 이러한 2가지 방법은 필수로 선택해야 하는 기법이다.
3.5 애그리거트 간 집합 연관
1-N과 M-N 연관에 살펴보자. 이 두 연관은 컬렉션을 이용한 연관이다. 애그리거트 간 1-N 관계는 Set과 같은 컬렉션을 이용해 표현할 수 있다. 하지만 개념적으로는 애그리거트 간 1-N 연관이 있더라도 성능 문제 때문에 실제 구현에 반영하지 않는다. 예로 카테고리에 속한 상품을 구할 필요가 있다면 상품 입장에서 자신이 속한 카테고리를 N-1로 연관지어 구하면 된다. 이를 구현 모델에 반영하면 Category로의 연관을 추가하고 그 연관을 이용해서 특정 Category에 속한 Product 목록을 구하면 된다.
M-N 연관은 개념적으로 양쪽 애그리거트에 컬렉션으로 연관을 만든다. 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M-N 연관을 맺는다. 개념적으로는 상품과 카테고리의 양방향 M-N 연관이 존재하지만 실제 구현에서는 상품에서 카테고리로의 단방향 M-N 연관만 적용하면 되는 것이다. RDBMS 이용해서 M-N 연관을 구현하려면 조인 테이블을 사용한다.
3.6 애그리거트를 팩토리로 사용하기
예로 고객이 특정 상점을 여러 차례 신고해서 해당 상점이 더 이상 물건을 등록하지 못하는 상태라고 가정하자. 도메인 기능을 넣기 위한 별도의 도메인 서비스나 팩토리 클래스를 만들 수도 있지만 이 기능을 Store 애그리거트에 구현할 수도 있다. Store 애그리거트의 createProduct()는 Product 애그리거트를 생성하는 팩토리 역할을 한다. 팩토리 역할을 하면서 중요한 도메인 로직을 구현하고 있다. 팩토리 기능을 구현했으므로 이제 응용 서비스는 팩토리 기능을 이용해 Product를 생성하면 된다.
이는 응용 서비스에서 더 이상 Store의 상태를 확인하지 않는다. Product 생성 가능 여부를 확인하는 도메인 로직을 변경해도 도메인 영역의 Store만 변경하면 되고 응용 서비스는 영향을 받지 않는다. 도메인의 응집도도 높아졌고, 이것이 애그리거트를 팩토리로 사용할 때 얻는 장점이다.
애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성하여야 한다면 애그리거트 팩토리 메서드를 구현하는 것을 고려해보자.