CEQ, CQRS, ES 가 무엇일까?

회사에서 클래스 네임과 관련된 코드 리뷰를 받았는데, 클래스 명명에서도 고려해야 할 점이 있음을 알게 되었다.

이는 CQRS와 ES(event sourcing)에서 많이 쓰이는 패턴이다. 따라서 CQRS와 ES가 궁금해져서 간단히 찾아보았다.

CQRS & ES

• Commands
  • 명령은 수신자에게 어떤 작업을 수행하도록 지시하는 메시지이다.
  • 명령의 작성자는 의도를 가지고 있으며 수신자의 응답을 기대한다.
  • 시스템의 상태를 변경하므로, 두번 이상 처리되어서는 안된다.
  • 명령의 생산자는 때로는 순서대로 처리 되기를 원한다.
• Events
  • 과거에 일어난 일에 대한 사실을 전달한다.
  • 어떤 행동으로 이어질 기대가 없다.
  • producer는 대가로 어떤 응답도 기대하지 않는다.
  • 발생한 일에 대한 알림만 전달하므로 가볍다.
• Publisher/subscriber semantics
  • 소비자는 소비 시나리오에 따라 구독을 신청하고, 이벤트를 듣고, 조취를 취한다.
  • 이벤트는 여러명의 구독자가 있거나, 전혀 없을 수도 있다.
  • 서로 다른 구독자가 서로 다른 행동으로 이벤트에 반응하며, 서로를 인식하지 못할 수도 잇다.
  • 일반적으로 이벤트 구독은 메세지 브로커 같은 중개자가 있다. 퍼블리셔가 이벤트를 보내면, 브로커는 관심있는 구독자에게 라우팅하는 구조이다.
• Query
  • 무언가를 조회하는 요청이다.
  • 쿼리는 시스템 상태를 변경하지 않고, 그대로 유지하므로 부작용이 없다.
  • 쿼리는 HTTP나 gRPC같은 프로토콜을 통해 구현할 수 있는 동기식 작업이다.

명령과 이벤트를 선택하는 기준?

• 명령
  • 소비자는 메세지를 한번만 처리해야 하고, 그 이상 처리하지 않아야 할 경우
  • 메세지가 순서대로 처리 되길 기대할 때
  • 생산자는 수신자로 부터 작업완료를 확인하는 응답을 기대할 때
• 이벤트 사용하는 경우
  • 이벤트 생산자와 소비자 간의 연결이 느슨하여, 이벤트 수신자를 전혀 알지 못하는 경우
  • 상태 변경 이벤트를 관심 있는 서비스나 컴포넌트에 한번 쓰고 잊어버리는 방식으로 브로드 캐스트 하는 경우

CEQ 패턴

• Command를 하는 경우 commandExecutor, Query를 하는 경우 queryProcessor와 같은 명명법을 쓴다. 각각의 명명법은 동사 명령형을 따른다.
• 이벤트는 과거형을 쓴다.

예를 들어, 멤버를 create하는 경우 CreateUserCommandExecutor, 멤버를 찾는 경우 FindUserQueryProsser 같은 형식이다. 이벤트의 경우는 과거형으로 UserCreated 같이 쓴다.

참고 자료

https://github.com/dhslrl321/cqrs-journey-guide-korean

https://medium.com/event-driven-utopia/using-commands-events-and-queries-in-microservices-communication-3573f1fcfafe