11.1 단일 모델의 단점

• 조회 화면 특성상 조회 속도가 빠를수록 좋은데 → 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야한다.
• 애그리거트 참조 방식에 따른 한계점
  • 식별자 참조 방식
    • 즉시로딩같은 JPA 쿼리 관련 최적화 기능 사용할 수 없다
  • 직접 참조 방식
    • 조회 화면 특성에 따라 같은 연관 → 즉시/지연 로딩으로 처리
    • DBMS 기능 필요하면 네이티브 쿼리 사용해야 한다

⇒ 시스템 상태를 변경하는 경우와 조회하는 경우 단일 도메인 모델을 함께 사용하기 때문이다

⇒ JPA 같은 ORM 의 경우 도메인 상태 변경 기능을 구현하는데는 적합

but 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 고려점이 많음 → 구현 복잡

11.2 CQRS

• 시스템이 제공하는 기능
  • 상태를 변경하는 기능(Command)
    • 한 애그리거트의 상태를 변경한다
  • 상태 정보를 조회하는 기능(Query)
    • 두개 이상의 애그리거트가 필요한 경우가 많다

⇒ 상태를 변경하는 범위 ≠ 상태를 조회하는 범위

• Command Query Responsebility Segregation

  • 상태를 변경하는 모델과 상태 정보를 조회하는 모델을 분리한다

• 복잡한 도메인에 적합하다 → 도메인이 복잡할수록 명령/조회 기능이 다루는 데이터가 차이난다

구현

• 각 모델에 맞는 구현 기술을 선택하면 된다
  • 명령 모델 - JPA, 조회 모델 - 마이바티스

설계

• 명령 모델 → 객체를 기반으로 설계, 상태 변경 도메인 로직 수행에 초점