• 조회성능 높이고 싶거나 데이터를 관리하는 영역과 뷰로 전달하는 영역의 책임이 나뉠때, 시스템 확장성을 높이고 싶을때 사용

• 명령과 조회의 모델(도메인객체) 구분, 조회용(노출용) 모델을 따로 만들때는 DTO를 추천

• 명령모델 데이터가 변경되는 시점에 조회모델 생성/저장 → 비정규화된 데이터 그 자체를 그대로 조회에 이용(적은 수정 & 많은 조회 모델에서 효과 극대화)

  

• 이벤트 소싱 패턴

  • 변경된 상태 이벤트 퍼블리싱

  • 분리된 어플리케이션에서 이벤트를 소비하여 조회모델 생성

    

• 조회모델 설계하기

  • 필요한 정보만을 담아 조회시 그대로 이용할 수 있도록 설계하는 것이 핵심

• 변경 감지 대상 선정과 이벤트 선정

  • 이벤트 발행할 내용
    • 변경에 따라 갱신해야할 대상 id
    • 모든 속성을 감지하면 성능이슈 → 변경 감지할 property 지정(optional)
    • 생성/수정/삭제 중 실행 method 지정(optional)
    • data 변경자, 이름등의 부수 정보
  • 이벤트 발행
    • 변경 내역 전체를 전송하면 오히려 로직 복잡성 높음
    • id만 전달해서 조회 모델 생성
  • interface

    • 각 감지 대상 엔티티마다 interface 구현하도록 강제함

      

    • 감지 대상 엔티티 지정

      

• 데이터 변경 감지하기

  1. JPA EntityListeners

     1. 엔티티 변경 라이프사이클 발생시 원하는 시점을 콜백받을 수 있음
     2. 가장 간단함
     3. 해당 엔티티만 인자로 반환하기 때문에 변화에 대한 자세한 데이터를 모름

  2. Hibernate EvnetListener(기본)

     1. SessionFactoryImpl → SessionFactoryServiceRegistry → EventListenerRegistry

     2. 26가지 디테일한 상황에 콜백

     3. 보다 상세한 정보 전달(변경된 프로퍼티)

     4. 모든 엔티티 변경 사항이 전달됨(원하는 엔티티 즉, 변경감지 대상 엔티티만 걸러주는 작업이 필요함)

        

  3. Hibernate Interceptor

     1. Session 혹은 SessionFactory 생성 시점에 주입하면 Interceptor 등록 가능
     2. EventListener에 비해 적은 콜백 종류
     3. 저장될 데이터를 인터셉터 시점에 조작가능하다는 위험 && 편리한 장점

  4. Spring AOP(delete bulk Query처럼 엔티티매니저 라이프사이클 타지 않을때 예외적으로 사용)

     1. pointCut 문법으로 실행 상황 지정할 수 있음
     2. 새로운 메서드 생성시마다 고려해줘야함

• Amazon SNS, SQS 사용

• 이벤트 로깅
• 변경 대상 버퍼에 저장
• 스케줄러 활용 10초에 한번씩 버퍼에 있는 모든 요청을 가져와 조회모델 bulk로 생성

더 나은 설계 구조