학습자료
- 최범균, 도메인 주도 개발 시작하기
JPA의 @ManyToOne, @OneToOne과 같은 어노테이션을 활용해서 연관된 객체를 로딩할 때의 생길 수 있는 문제
- 아래와 같이 어노테이션을 활용한 애그리거트를 직접 참조(필드 or getter 이용)
@Entity
@Table(name = "orders")
public class Order {
@Id @GeneratedValue
@Column(name = "order_id")
private Long id;
// member를 직접 참조
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;
... 생략1. 편한 탐색 오용
- 애그리거트 내부에서 다른 애그리거트의 객체에 접근 할 수 있다면 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.
- order에서 배송되는 주소를 새롭게 입력할 수 있다면, 그 정보로 member의 주소 또한 변경할 수 있다.
- 다른 애그리거트의 상태를 변경하도록 하면, 애그리거트 간의 의존 결합도를 높이고, 변경을 힘들게 한다.
2. 성능에 대한 고민 (FetchType)
- 영한님의 강의에 따르면 실무에서는 정말 단순한 객체가 아니면
Eager의 활용은 실무에서 절대 사용해서는 안된다. - 성능적인 고민에 대해서는 나와 같은 초보자가 정확하게 이해하지 못하고, 직접 참조를 통한 사이드 이펙트를 만드는 경우와 코드가 복잡해지는 경우를 문제삼는 것 같다.
3. 확장 어려움
- 처음 서비스를 시작할 때는, 단일 DBMS로 서비스를 제공하는 것이 가능하지만, 사용자가 늘고 트래픽이 증가하게 되면 부하를 분산하게 된다.
- 이 때, 하위 도메인 별로 시스템을 분리하게 되는데, 도메인 마다 서로 다른 DBMS를 사용할 때도 있다.
- 이 경우에 JPA만으로 해결할 수 없다는 문제점이 있다.
해결책 : foreign key처럼 ID를 통한 참조?
- 영한님의 강의를 들으면서 jpa를 활용이 객체를 참조하는 것으로 객체지향적인 도메인 객체를 생성하는 것이 큰 장점이라고 여겨졌다.
- 하지만 책에서 제시하는 방법은 DB의 테이블처럼 foreign key를 가지고 있도록 객체를 구성하는 것이다.
- 이 방법을 통하면 애그리거트간의 의존성을 제거해서 응집도를 높혀주는 효과가 있다.
- 또한, 참조하는 애그리거트가 필요할 때 그때 쿼리를 보내게 되어 지연로딩과 같은 효과를 보인다.
- 그리고 확장의 어려움에서 언급했듯이, 각 애그리거트가 다른 DBMS를 사용할 수도 있다.
성능 이슈
- N+1 조회 문제
- JPQL를 활용해서 조회 전용 쿼리를 작성하는 것으로 문제를 해결할 수 있다.
- 이 문제는 직접 참조해서 지연로딩시에도 생길 수 있는 문제
영한님 강의를 통해 jpa를 입문하는 입장으로 어쩌면 반대되는 방법 같아서 혼란스럽기도 하다.
영한님 강의와 책을 통해서 계속 고민해봐야할 문제이다.
차곡차곡