6주차 - CQRS

💡CQRS란?

CQRS는 데이터 변경과 조회의 책임을 나누는 것.

(명령과 조회의 책임을 분리 - Command and Query Responsibility Segregation)

명령 ⇒ Command (데이터 변경)

조회 ⇒ Query (데이터 조회)

 

 

💡예를들어보자.

명령(Command : 데이터변경) → 회원 데이터의 회원상태를 변경.

조회(Query : 데이터조회) → 회원을 조회하는 것.

위 두가지에서 사용되는 모델은 각각의 모델로 분리하여야 한다.

⁉️만약 분리하지않는다면 ???

하나의 가정을 잡고 설명하고자 한다.

• Member라는 모델 객체에서는 변수 name, age, status, date ( 각각 이름, 나이, 상태, 가입일 )가 있다고 가정한다.
• 회원의 처음 상태는 준회원이라고 가정한다.
• 조회하는 기능에는 name, age 를 조회하여 화면에 보여준다. (데이터 조회)
• 회원은 3일 이후 접속하면 상태(status)를 정회원이라는 상태로 변경한다 (데이터 변경)

이때에 **조회(Query)**와 데이터 변경(Command) 둘다 Member 변수를 사용하고 있다면..

 

단일 책임원칙인 SRP를 위반하는 것이다.

 

왜냐하면 Member 객체는 조회와 데이터변경 두가지 역할을 가지기 때문이다.

또한, 추후에 Member 객체에 기능(메서드)변경이 이뤄지거나, 필요한 변수가 추가되거나 하는 변경이 생겼을때 문제가 발생한다.

추가되는 변경점은 아래와 같다.

• gender가 추가되고, 여성일 경우 가입하고 하루만 지나도 정회원으로 변경되어야 한다.
• 성별은 조회기능에서 보이지 않아도 된다.

Member내에 그럼 gender라는 변수가 추가되었고, 조회에서는 사용하지 않는 변수가 되었다.

또, Member객체 안에는 기능(메서드)으로 심지어 isUpdate() 라는 메서드도 생겼고, true / false 를 리턴하는 것도 추가 하였다고 가정한다면 Member객체의 덩치는 커질 것 이다.

단지, gender변수는 데이터변경에서만 쓰이는 기능이며 변수이다.

이렇게 시간이 지나면 지날수록 요구사항들이 추가되면서 Member의 객체의 덩치는 점점 커질 것이다. (안티패턴)

추후에 필요없는 기능이나 변수를 삭제할때 조회와 데이터변경 등이 미칠 영향도까지 고려해야한다.

이렇게되면 유지보수성이 🔻떨어진다.

때문에, 중복되는 변수가 있다고 하여도, 클래스에 변수가 2개만있다고 하더라도, 따로 만들기를 권장한다.

이는 ..

• 클래스의 역할이 뚜렷해지고,
• 클래스가 작아지며, 
• 유지보수성이 높아지고,
• 성능확장에도 유리하게 된다.

💡즉, 조회와 변경 모델을 각각 따로 만들어야 한다. → CQRS