CQRS

..

사용자가 필요로 하는 데이터 뷰를 리파지토리로 쿼리하기란 어려울 수 있다. 
특히 사용자 경험 설계가 여러 애그리게잇 타입과 인스턴스로부터 데이터 뷰를 생성해야 할 때가 어렵다. 
여러분의 도메인이 정교할수록 이런 상황이 발생할 가능성이 높아진다.
(말이 어렵게 표현되어 있는데, 여러 DB 또는 여러 Table 또는 여러 System에 흩어진 데이터를 한번에 조회(쿼리)하기 어려운 경우가 있다는 말이다)

도메인 데이터를 뷰에 매핑하는 완전히 다른 방법이 있을까? 
이 질문에 대한 대답으로, 이상한 이름을 가진 아키텍처 패턴인 커맨드-쿼리 책임 분리
(CQRS : Command-Query Responsibility Segregation) 가 있다. 
이 아키텍처는 엄격한 객체（또는 컴포넌트）의 설계 원칙과 커맨드-쿼리 분리 CQS 를 아키텍처 패턴으로 녹여내기 위해 노력한 결과다. 버트랜드 마이어(Bertrand Meyer)에 의해 고안된 이 원리에선 다음과 같은 내용을 따르고 있다.

모든 메소드는 작업을 수행하는 커맨드이거나 데이터를 호출자에게 반환하는 쿼리 중하나여야 하며. 
하나의 메소드가 두 역할을 모두 할 수는 없다. (Command (CUD 저장) 또는 Query(조회) 둘 중 하나)

이제 전통적으로 모델에서 찾게 되는 모든 순수 쿼리 책임을, 같은 모델의 순수 커맨드를 실행하는 책임으로부터 분리한다고 생각해보자. 애그리게잇은 쿼리 메소드(게터) 없이 오직 커맨드 메소드만을 포함하게 된다. 리파지토리는 add() 나 save() 메소드 ... 와 같은 단 하 나의 쿼리 메소드로 분해된다. ... 그 결과를 커맨드 모델로 지정한다. 우리는 여전히 사용자에게 데이터를 보여줄 방법이 필요하다. 이를 위해선 최적화된 쿼리에 맞춰 두 번째 모델을 생성한다. 이를 쿼리 모델이라고 한다. 
...
내가 쿼리 모델이라고 부른 대상은 읽기 모델로도 알려져 있으며, 커맨드 모델은 쓰기 모델로도 불린다.
결과적으로 전통적 도메인 모델은 둘로 분리된다. 커맨드 모델과 쿼리 모델은 서로 다른 저장소에 저장된다.

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p206~208

 

 

..

결국은 일관성이 유지되는 쿼리 모델 다루기

만약 쿼리 모델의 일관성이 결국은 유지되도록 (Eventually Consistent) 설계
(커맨드 모델 저장소로의 쓰기에 따라 쿼리 모델 업데이트가 비동기적으로 일어나는 경우)

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p216

 

..