[DDD START!] 5장. 리포지터리의 조회 기능

repository는 애그리거트의 저장소

find 메서드 정의로 조회를 할 수 있지만, 너무 많아지고 조합이 다양할 경우 스펙(Specification)을 이용

 

스펙(specification)은 애그리거트가 특정 조건을 충족하는지 여부를 검사

 

public interface Speficiation<T> {
	public boolean isSatisfiedBy(T aggregation);
}


public class OrdererSpec implements Specification<Order> {

	private String orderId;
    
    public OrdererSpec(String ordererId) {
    	this.ordererId = ordererId;
    }
	@Override
    public boolean isSatisfiedBy(Order order) {
    	return order.getOrderId().getMemberId().getId().eqauls(orderId);
    }
}

조합되 스펙을 다시 조합해서 더 많은 스펙을 만들 수 있다.

하지만, 이는 메모리에 로딩한 후 루프를 돌면서 스펙을 검사하는 것으로 느리다.

-> CriteriaBuilder, Predicate를 이용해서 검색 조건을 구현한다.

 

라퍼지터리 구현 기술 의존

도메인 모델은 구현 기술에 의존하지 않아야 한다.!!!

그런데...Specification 인터페이스는 toPredicate()가 Root와 CriteriaBuilder에 의존하고 있으므로, 이미 JPA에 의존하는 모양이 된다.

-> 이를 해결하려면, 추상화를 해야하는데 repository 구현 기술의 변화는 드물기 때문에, 이점이 크지 않다.

 

조회 전용 기능 구현

리포지터리는 애그리거트의 저장소를 표현하는 것으로 다음 용도로 사용하는 것은 적합하지 않다.

- 여러 애그리거트를 조합해서 한 화면에 보여주는 데이터 제공

- 각종 통계 데이터 제공

 

애초에 이런 쿼리는 조회 전용 쿼리로 처리해야 하는 것이다.

동적 인스턴스 생성, @Subselect, 네이티브 쿼리를 이용해서 구현할 수 있다.