1. 모듈 위치
: 2장에서 언급했듯 리포지터리 인터페이스는 애그리거트와 같이 도메인 영역에 해당하며 리포지터리를 구현한 클래스는 인프라스트럭처 영역에 속한다.
: 팀 내 표준에 따라 리포지터리 구현 클래스를 domain.impl과 같은 패키지에 위치시킬 수도 있지만 이것은 리포지터리 인터페이스와 구현체를 분리하기 위한 단순한 계책일 뿐 좋은 설계는 아니다.
: 가능하다면 리포지터리 구현 클래스를 인프라스트럭처 영역에 위치시켜서 인프라스트럭처에 대한 의존을 낮춰야 한다.
2. 리포지터리 기본 기능 구현
: 리포지터리가 제공하는 기본 기능은 다음 두 가지다.
•
ID로 애그리거트 조회하기
•
애그리거트 저장하기
public interface OrderRepository {
Order findById(OrderNo no);
void save(Order order);
}
Java
복사
: 인터페이스는 애그리거트 루트를 기준으로 작성, 주문 애그리거트는 Order 루트 애그리거트를 비롯, OrderLine, Orderer, ShippingInfo 등 다양한 객체를 포함하며 이 구성요소 중 루트 엔티티인 Order를 기준으로 리포지터리 인터페이스를 작성한다.
: 스프링과 JPA로 구현한다면 리포지터리 구현 클래스는 스프링 데이터 JPA 가 알아서 만들어준다.
: 애그리거트를 수정한 결과도 JPA를 사용하면 트랜잭션 범위에서 변경한 데이터를 알아서 DB에 반영하기 때문에 메서드를 별도로 추가해줄 필요가 없다.
: @Transaction 어노테이션을 단 서비스 레이어의 메서드를 실행한 결과로 애그리거트가 변경되면 JPA 는 자동으로 Update 쿼리를 실행한다.
⇒ 너무 싱기행..
: ID가 아닌 다른 조건으로 애그리거트를 조회할 때는 findBy 뒤에 조건 대상이 되는 프로퍼티 이름을 붙인다. 특정 ID가 주문한 Order 목록을 구하는 메서드는 findByOrdererId(String ordererId, int startRow, int size)와 같이 정의할 수 있다.
: ID 외의 다른 조건으로 애그리거트를 조회할 때에는 JPA의 Criteria나 JPQL을 사용할 수 있다.
