3장 애그리거트

[tidavid1]

3장 애그리거트를 읽고 코멘트를 남겨주세요

[YongNyeo]

애그리거트 id 클래스를 모두 따로 생성하는게 과연 효율적일까? (p.117)

java
public class Member {
        private MemberId id; // -> 이거
        //...
}    

책에서 연속된 객체 참조때문에 비효율적인 측면을 제시했는데,  jpa의 fetch기능과 이용하면 되지 않을까?

공통의견 : jpql을 사용하면 객체 참조문제 또한 해결할 수 있다!

[voidmelody]

흔히 'A가 B를 갖는다'로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 하지만 'A가 B를 갖는다'로 해석할 수 있는 요구사항이 있다고 하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다. 좋은 예가 상품과 리뷰이다. 상품 상세 정보와 함께 리뷰 내용을 보여줘야한다라는 요구사항이 있을 때, Product 엔티티와 Review 엔티티가 하나의 애그리거트에 속한다고 생각할 수 있다. 하지만 Product와 Review는 함께 생성되지 않고, 함께 변경되지도 않는다. 게다가 Product를 변경하는 주체가 상품 담당자라면, Review를 생성하고 변경하는 주체는 고객이다.

생성 주기와 변경 주체를 고려해보며 해당 엔티티가 동일한 애그리거트 범위에 속하는지 여부를 판단해야한다..!

[tidavid1]

애그리거트를 직접 참조할 떄 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다는 것이다. 한 애그리거트 내부에서 다른 애그리거트 객체에 접근 할 수 있다면 다른 애그리거트의 상태를 쉽게 변경 할 수 있게 된다.

JPA의 효용성 중 큰 부분을 차지하는 것이 직접 참조라고 생각했는데, 편리함의 오용을 이유로 ID를 통한 간접 참조로 코드에서 계속 반복호출하는 방식이 효율적인지에 대해서 고민을 해보면 좋을 것 같습니다.

[happyjamy]

애그리거트를 직접 참조할 떄 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다는 것이다. 한 애그리거트 내부에서 다른 애그리거트 객체에 접근 할 수 있다면 다른 애그리거트의 상태를 쉽게 변경 할 수 있게 된다.

저도 이 부분에서 애그리거트 루트를 통해서만 데이터를 변경하는 것이 옳다고 생각해서 연관관계를 맺을때 편리함뿐만 아니라 도메인적으로 한번 더 생각해야 함을 느꼈습니다

[suzzingV]

애그리거트에 대해 이해하게 되었고, 조회 성능에 대한 내용에[ 대해 토론해보면서 최적의 방법을 생각해내는 것이 흥미로웠습니다.

[JIN-076]

Q. 애그리거트 간의 일대다 연관의 성능 문제를 값 타입 컬렉션을 이용해 해결하는 게 최선일까? (3.5 애그리거트 간 집합 연관 p123-124) (홍지인)

경민: 1:N에서의 로딩의 문제점을 예시를 보여주면서 N:1 의 매핑이 중요하다를 보여주기 위한 의제와 개념상의 M:N 양방향 매핑을 실제 구현하는 방향에서는 단방향으로의 구현의 방식을 제안하는 제안과 실제 구현에서의 문제점의 고민의 충돌이지 않을까?

공통 의견: JPA 타입의 값 타입 컬렉션은 변경이나 수정이 일어나면 관련된 모든 데이터를 지웠다가 새로 입력해야 하는 번거로움이 존재한다. 때문에 사용하고자 하는 데이터의 양이 많지 않고 수정이나 변경이 자주 발생하지 않는다면 (예를 들어, INSERT만 발생하는 등) 일대다 연관보다 좋은 값 타입 컬렉션이 좋은 성능을 보일 수 있으나, 수정이나 변경이 잦고, 데이터의 양이 많다면 일대다 연관관계를 고려하는 것이 좋을 듯 하다.

[JIN-076]

애그리거트라는 개념을 처음 접하게 되었는데, 애그리거트를 구성할 때에 대해서 생성 주기와 변경 주체, 함께 변경되는 빈도 등을 고려해보면서 요구사항을 토대로 애그리거트를 잘 설계하는 것의 중요성을 이해하게 되었다. 애그리거트를 활용하는 과정에서 일관성을 유지하기 위해 루트만을 통한 상태 변경을 가능하도록 하는 등, 전반적인 애그리거트의 구성과 지켜야 할 활용 규칙에 대해서 잘 이해하게 되었다. 흥미로웠다!