Command Query Responsibility Segregation
쉽게 말해 시스템 데이터를 변경하는 코드와 조회하는 것을 분리한다는 것이다. 물론 코드만 나누는 것은 아니다. 시스템 규모에 따라 db를 나누기도하고, 프로세스를 나누기도 한다. 어쨋든 변경하는 요소와 조회하는 요소를 분리하는 것이다.
Member 클래스가 더이상 Member 테이블에 대응하는 모델이 아닌다. LOGIN_HISTORY 테이블과도 엮이고 ORDER 테이블과도 엮인다. 역할과 책임이 모호해지고, 의마와 가독성도 나빠진다.
기능에 따라 연관해야하는 것들이 달라져야 하니 복잡해진다.
그렇다면 왜 복잡해지는 시스템에서 커맨드와 커리의 단일 모델을 구성하면 유지 보수성이 떨어질까?
가장 큰 이유는 명령과 쿼리가 다루는 데이터가 다르다.
명령과 쿼리는 코드 변경 빈도, 사용자도 다르다.
기능마다 성능 요구도 다르다.
다양한 CQRS 구현 형태
구현: 같은 프로세스, 같은 DB
가장 단순하고 트랜잭션 처리도 쉽다.
구현: 같은 프로세스, 같은 DB, 다른 테이블
같은 db에서 별도 테이블을 사용하는 것이다. 하지만 보통 명령이 쿼리 전용 테이블을 변경한다.
구현: 같은 프로세스, 다른 DB
구현: 다른 프로세스, 다른 DB
다른 DB로 변경 전파
방법이 세 가지가 있다.
첫 번째는 제일 왼쪽에 있는 것이다. 명령이 db를 직접 수정하는 방법이다. 카프카 같은 메시징 전송 수단을 이용할 수도 있다. 하지만 이것은 데이터 유실 가능성도 있다.
두 번째는 변경 내역을 기록하고 별도 전파기를 이용해서 변경 내역을 전달하는 방식이다. 명령은 상태를 변경하고 변경 내역을 테이블에 기록하고, 이 과정이 한 트랜잭션에 구현되기 때문에 데이터 유실은 되지 않는다.
세 번째는 db가 제공하는 cdc를 이용하는 것이다.
다른 db 사용시 주의 사항
