11장 : CQRS

단일 모델의 단점

식별자를 이용해서 애그리거트를 참조하는 방식을 사용하면 즉시 로딩 방식과 같은 JPA 쿼리 관련 최적화 기능을 사용할 수 없다.이는 한 번의 SELECT 쿼리로 조회 화면에 필요한 데이터를 읽어올 수 없어 조회 성능에 문제가 생길 수 있다.

애그리거트 간 연관을 직접 참조하는 방식으로 연결해도, 조회 화면 특성에 따라 같은 연관도 즉시 로딩이나 지연 로딩으로 처리해야 하기 때문에 고민거리가 생긴다. 조회 기능을 구현할 때 DBMS가 제공하는 전용 기능이 필요하면 JPA의 네이티브 쿼리를 사용해야 할 수도 있다.

ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 구현을 되려 복잡하게 만든다.

상태 변경을 위한 모델과 조회를 위한 모델을 분리하 것은 구현 복잡도를 낮춰준다.

CQRS

시스템이 제공하는 기능은 크게 상태를 변경하는 기능과 상태 정보를 조회하는 기능이다.

도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다. 반면에 조회 기능에 필요한 데이터를 표시하려면 두 개 이상의 애그리거트가 필요할 때가 많다.

상태를 변경하는 범위와 상태를 조회하는 범위가 정확하게 일치하지 않아 단일 모델로 두 종류의 기능을 구현하면 모델이 불필요하게 복잡해진다.

CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령(Command)을 위한 모델과 상태를 제공하는 조회(Query)를 위한 모델을 분리하는 패턴이다.

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다. 명령 모델은 객체 지향에 기반해서 도메인 모델을 구현하기에 적당한 JPA를 사용해서 구현하고, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 마이바티스를 사용해서 구현하면 된다.

웹과 CQRS

  • 조회 속도를 높이기 위해 별도 처리를 하고 있다면 명식적으로 명령 모델과 조회 모델을 구분하자. 이를 통해 조회 기능 때문에 명령 모델이 복잡해지는 것을 막을 수 있고, 명령 모델에 관계없이 조회 기능에 특화된 구현 기법을 보다 쉽게 적용할 수 있다.

CQRS 장단점

  • 장점

    • 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다.

    • 조회 성능을 향상시키는 데 유리하다.

  • 단점

    • 구현해야 할 코드가 더 많다.

    • 더 많은 구현 기술이 필요하다.

Last updated